I love sharing from my 23 years of experience working with systems to create software (organizational culture, processes and technology choices). I am open to speaking at conferences and meetups. Find me at Advanced Software Mastermind together with awesome peers and friends in the industry.

startupconfessions.io, Lisbon

Planned events

Operation Code, Founders’ Roundtable, July 9th 2020

Previous events

NameTopic
Domain-Driven Design Showcase 
Maryland Patterns & Practices
Washington D.C., May 19th, 2020
Walkthrough of an example application of Domain-Driven Design principles
The Saga pattern
Advanced Software Mastermind
Lisbon, Mar 3rd, 2020
Walkthrough of the Saga pattern and example application
Domain-Driven Design Showcase
Advanced Software Mastermind
Lisbon, Mar 2nd, 2020
Walkthrough of an example application of Domain-Driven Design principles
Domain-Driven Design Showcase 
Operation Code, Microsoft
Washington D.C., Feb 20th, 2020
Walkthrough of an example application of Domain-Driven Design principles
The Saga pattern
Full Stack DC
Washington D.C., Jan 19th, 2020
Walkthrough of the Saga pattern and example application
Exploring Disney’s Integration Matrix
Lisbon, Jul 17th, 2019
An investigation of Disney’s Integration matrix and example of application in Position Green
Udi Dahan’s Advanced Distributed Systems Design
Lisbon, June/July, 2019
Lead a local study group of Udi Dahan’s ADSD online course over 5 weeks.
Domain-Driven Design Showcase 
Lisbon, March 16, 2017
Walkthrough of an example application of Domain-Driven Design principles
Event-Driven Architecture
Malmö, Jun 14th, 2013
Walking through the business advantages of adopting an Event-Driven Architecture – with examples
Event-Driven Architecture
Malmö, Nov 28th, 2012
Walking through the business advantages of adopting an Event-Driven Architecture – with examples

Abstracts

startupconfessions.io

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
  • Aggregates
  • Services
  • Commands
  • 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.

The Saga Pattern, Washington D.C.

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