Speaker bio

Entrepreneur with a passion for leadership, technology-based business scaling and product development. I work towards bringing service excellence into every team, process and product in IT and software development.

With a proven track record on more than 60 public and private sector projects and over 22 years of custom software project experience, my expertise is creating strategically aligned systems and bringing positive change, excellence and technology-agnostic growth to organizations and their employees.

  • Co-founder of Position Green
  • Has experience with event-driven architecture since 2012
  • Founder of Lisbon Domain-Driven Meet-up
  • NServiceBus Community Champion since 2012
  • Independent consultant since 2003
  • Works out of Washington D.C., USA

Sessions 2020

Christer Østergaard


The reasons for using Domain-Driven Design are relatively easy to understand and identify with: the strategic goals of creating and maintaining a shared language with least possible ambiguity, the idea of dividing a system into separate parts by identifying bounded contexts, and using tactical patterns and technologies to realize the solution in code. It makes sense!

Startup Confessions

However, while some parts of Domain-Driven Design amplify the best of years of collective industry experience for application implementation, they also require us to steer away from patterns we tend to use as implementation standards. This can be confusing and daunting at first. Domain-Driven design may introduce what seems to be extra overhead at times or near-equal representations of a concept in different contexts. However counter-intuitive this may be initially, using Domain-Driven Design can result in long term benefits.

To help you succeed with your Domain-Driven Design initiatives, we will go through concepts and code of a simple domain model that has been running in production since 2013 on startupconfessions.io. The application is easy to understand as a DDD example, with bounded contexts, aggregates, events, messaging and database infrastructure.

By the end of this session, you will:

  • Know how the concepts of Domain-Driven can look like in code
  • Be able to reason on bounded contexts and the division of responsibilities in a system
  • Have gained insight on messaging infrastructure from a Domain-Driven Design perspective

<< Back to Schedule

The Saga pattern

Advanced business process implementations are typically a mix of steps that require human inputs and steps that are set to react to inputs from other applications or services, or the passing of time. Batch jobs are often the de facto choice to implement the steps that are automated and repeated.

However, batch jobs are actually ill-fitted for process implementations: While long running processes will often require their own state and are a core part of the business domain, batch jobs are often thought off as stateless, 2nd grade parts of the whole. They consist of code you write once and hope never to read or change, and keeping state correct over time is overly complex. On top of that, they’re known for aggressively bogging down our production databases because of ill fated combinations of large transactions scopes, N+1 data traversal, isolation levels and amount of data processed.

There is a better way: The Saga pattern. The Saga is a much better way of representing a process in code that will be much more true to the conceptual process definition, and is much more readable, extensible and open to change. By virtue of supporting technology, an instance of a Saga will be able to execute and react in near-realtime.

The Saga pattern

In this session we go through the Saga concept and walk through several code examples, from simple scheduler-like implementations related to integration, to multi-dimensional processes.

By the end of this session, you will know:

  • What a Saga is
  • How a Saga is used
  • Which platforms you can use to make your own Sagas

<< Back to Schedule