Transcript
Page 1: Domain Driven Design and Command-Query Responsibility ...storage.googleapis.com/xebia-blog/1/2009/11/DDD-Erik-Rozendaal.pdf · Domain Driven Design and Command-Query Responsibility

D o m a i n D r i v e n D e s i g n a n d C o m m a n d - Q u e r y R e s p o n s i b i l i t y S e g r e g a t i o n

E r i k R o z e n d a a l S o f t w a r e D e v e l o p m e n t

Client

DomainReporting

Commands

Events

Query Results

Application Flow

Events

Queries and Reporting

Denormalizer

Query Database

Thin Query Layer

updates

query results

Que

ry

Result

sTransactional Domain

Command Handler

Repository

Aggregate

Event Store

1: get aggregate5: save aggregate

2: load events for aggregate7: save events for aggregate

3: instantiate with event history6: get change events

4: execute command

Commands

Events

Benefits• Rich domain that only exposes behavior

• Queries do not use the domain model

• No need for object-relational mapping

• Bullet-proof auditing and historical tracing

• Easy integration with external systems

• Performance and scalability

• Testability

Command-Query Separation• Separate Commands that change state from

Queries that read state

• All state changes are represented by domain Events

• Aggregates receive Commands and publish Events

• The Query database is updated as a result of the published Events

• All Queries go directly to the Query database, the domain model is not involved

Top Related