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.
- 2 x CTO
- Co-founder of Position Green
- Experienced 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
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!
So let’s get concrete with Domain-Driven Design in this walk-through of code in an in-production application. You will see application design and C# code covering:
- Bounded contexts
- Domain Events
- Message handlers
- Website tactics enabled by events
- Durable messaging infrastructure and tactics
- Strategies for error handling
- Strategies for message de-duplication
- Making the most of cache with infinite time-to-live (and using events to ensure cache bust at the right time)
- How Domain-Driven Design links to Event-Driven Architecture
You will also see
- startupconfessions.io Use Case diagram
- startupconfessions.io Sequence diagrams
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
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.
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