Menu

Subscribe

What is DDD? What is CQRS?

on design pattern, unlisted, DDD, CQRS, software systems

Domain Driven Design

  • DDD is an approach to developing software systems that is large and complex, and has ever-changing business rules.

  • DDD captures the sweet spot between the business knowledge and the code.

  • Building Blocks (to describe a domain model)
    • Entities: Ever-changing objects defined by identity
    • Values: Immutable (typically) objects,
    • Service: Stateless and cannot be modeled as an object
    • Aggregate: A group of the above elements, managing their complex relations.
    • Aggregate Root: Gatekeeper object for the Aggregate. Any kind of access with aggregates is made from the aggregate root only.

Bounded Context

  • Implies that you split a single large domain model into multiple small domains, for cleanliness and smoother design.
  • Bounded context is the context for one particular domain model
  • If you want each bounded context to share data to each other, use context maps.

Domain Model

  • The core of DDD
  • Captures what is valuable or unique to the business
  • i.e., aggregates, values, entities
  • Tries its very best to foster a common understanding between the domain experts and the developers.
    • The domain experts provide it with the relevant domain knowledge
    • The model is expressed in code by the developers

DDD <-> CQRS

  • DDD and CQRS share the same terminology
  • DDD is not a pre-requisite for CQRS but they are very similar
  • You can have a single bounded context use CQRS, with other bounded context using DDD.
  • CQRS offers a few solutions to issues with DDD (read below)

CQRS

  • A way of separating the read operations (a.k.a, queries) from the update operations (a.k.a, commands). This typically means having a separate read model and write model, or having a separate read store and write store.
    • PRO: Improves performance and scalability by using separate interfaces for the read and update. For example, if there are more reads than writes, then the read side can be fine-tuned separately from the write side.
    • PRO: Good for managing security and permissions because data isn't exposed in the wrong context like in CRUD user-interface, where read operations and update operations may share the same interface.
    • CON: May add unnecessary complexity. If an application can get away with CRUD implementations, then that should be used instead.
  • Simplifies design and implementation for large applications with ever-changing business rules
  • Read Model
    • Queries the data
    • Its main focus is to return a materialized view of the data to the UI. The data is tailored to the application's display or interface. Thus, it is optimized for display and query performance.
    • With Event Sourcing, the read model takes events and returns an updated DTO (Data Transfer Object) for use in a view model as a response to a client's query.
  • Write Model
    • Updates the data
    • With Event Sourcing, the store of events is the write model
    • The write model has a full command-processing stack with business logic, input validation, and business validation to ensure that everything is always consistent for each of the aggregates (each cluster of associated objects treated as a unit for data changes) in the write model.

Event Sourcing

  • Kind of like the butter in the idiom bread-and-butter, where the bread is a metaphor for CQRS.
  • Why Event Sourcing?: In a typical CRUD architecture, when data is being saved to the domain, only the current state of data is saved.
    • PRO: Event Sourcing combats this by instead appending the latest event to the write store. As a result, the write store maintains a stream of events. This saves you from the hassle of synchronizing data with the data model each time, which improves performance and scalability.
  • PRO: Leaves an audit trail, so that a stream or sequence of events can be replayed to project the current state of specific entities. They can also be replayed to examine the history of events.
  • Avoids update conflicts in a single aggregate.
  • CON: Adds complexity (code and design)
  • CON: A stream of events over a very long period can cost a significant amount of processing time. To combat this, a snapshot of the data generated at a scheduled interval can improve performance.
  • There will be some delay between the event being generated and the data store being updated.

References: https://msdn.microsoft.com/en-us/library/jj591560.aspx