Domain-Driven Design is a concept that focuses on the problems of specific knowledge areas. Command Query Responsibility Segregation (CQRS) separates a software into a write side and a read side. Event Sourcing is an architectural pattern that represents state as a sequence of immutable events.

Domains and models

A domain is the area of expertise about the problem-to-be-solved. In relation to DDD, the domain comes with some category definitions:

  • Domain Expert: the primary person(s) with understanding of the problem domain;
  • Subdomains: are parts of the entire information domain; divided into the following categories:
    • Core Domain: information area most relevant to the problem-to-be-solved
    • Supporting Subdomain: area of information that is parlty generic but nevertheless relevant to the problem-to-be-solved
    • Generic Subdomain: universal knowledge that is not specific to the main problem (on the list to outsource)

Domain Model is the structured abstraction (written English, diagrams and code examples) of the klowledge area, in terms of behavior and characteristics. Ubiquitous Language is the linguistic system valid in the context of a model, to make communication precise and effective.

The Domain Boundary is an explicit boundary within which a Domain Model (and the ubiquitous Language) exists. Larger models are more complex and harder to comprehend. With multiple simpler smaller models; the relationships and integrations between them can be designed as connections. There are multiple organizational and integration patterns:

  • Open Host Service: one software part must expose access to selected components
  • Anti-Corruption Layer: data from one part is used in a foreign context implementation
  • Published Language: an event-based message exchange is assumed

A ContextMap describes the bounded contexts and their relationships and integrations.

a Domain Model implementation should consist of a combination:

  • Value Objects: immutable object with attributes
  • Entities: unique elements that have a conceptual identity.

Domain events

Domain events are simply occurences within the domain, not purely technical since they contain meaningful knowledge. The primary goal is to establish loosely coupled messaging and therefore reduce and avoid direct dependencies. Minimally in includes the type , subject_id , custom data, an UUID and the creation time. Events are shared with something named an Message Bus that enables to publish messages and to notify registered subscribers. This procedure is called “topic-based distribution”.

some notes:

  • subscribers should take responsibility to overwrite duplicate received messages (with the same UUID)
  • subscribers are responsible for ordering of events: order is not guaranteed by the publisher

Aggregates

An aggregate is a cluster of domain objects that can be treated as a single unit; they are transactional consistency boundaries.

A transactions is a collection of opperations that is treated as a single unit; RDBS follow the ACID rules: Atomicity means that all operations are accepted of rejected, Consistency enforces rules upon all data items, all transaction occur in Isolation and Durability means that all is persistent. In DDD the transaction should not cross aggregate boundaries.

Repositories

Repositories provide an interface independant as possible of the underlying technology.

Optimistic Concurrency means that persist changes based on the actual state, done by version numbering. For every change request, the accompanied version is compared to the currently persisted one.

Resources

  • Lawrence, Alex. 2020. Implementing DDD, CQRS and Event Sourcing. Book
  • Evans, Eric. 2004. Domain-Driven Design: Tackling the Complexity in the Heart of Software.
  • Vernon, Vaughn. 2013. Implementing Domain-Driven Design.
  • Fowler, Martin. 2017. What do you mean by “Event-Driven”?. Web page