Home Page Icon
Home Page
Table of Contents for
Patterns, Principles, and Practices of Domain-Driven Design
Close
Patterns, Principles, and Practices of Domain-Driven Design
by Nick Tune, Scott Millett
Patterns, Principles, and Practices of Domain-Driven Design
Introduction
Overview of the Book and Technology
How This Book Is Organized
Who Should Read This Book
Source Code
Errata
p2p.wrox.com
Summary
Part I: The Principles and Practices of Domain-Driven Design
Chapter 1: What Is Domain-Driven Design?
The Challenges of Creating Software for Complex Problem Domains
How the Patterns of Domain-Driven Design Manage Complexity
The Practices and Principles of Domain-Driven Design
Popular Misconceptions of Domain-Driven Design
The Salient Points
Chapter 2: Distilling the Problem Domain
Knowledge Crunching and Collaboration
Gaining Domain Insight with Domain Experts
Patterns for Effective Knowledge Crunching
Look For Existing Models
The Salient Points
Chapter 3: Focusing on the Core Domain
Why Decompose a Problem Domain?
How to Capture the Essence of the Problem
How to Focus on the Core Problem
How Subdomains Shape a Solution
Not All Parts of a System Will Be Well Designed
What If You Have No Core Domain?
The Salient Points
Chapter 4: Model-Driven Design
What Is a Domain Model?
Model-Driven Design
Using a Ubiquitous Language to Bind the Analysis to the Code Model
Collaborating on a Ubiquitous Language
How to Create Effective Domain Models
When to Apply Model-Driven Design
The Salient Points
Chapter 5: Domain Model Implementation Patterns
The Domain Layer
Domain Model Implementation Patterns
The Salient Points
Chapter 6: Maintaining the Integrity of Domain Models with Bounded Contexts
The Challenges of a Single Model
Use Bounded Contexts to Divide and Conquer a Large Model
Implementing Bounded Contexts
The Salient Points
Chapter 7: Context Mapping
A Reality Map
Recognising the Relationships between Bounded Contexts
Communicating the Context Map
The Strategic Importance of Context Maps
The Salient Points
Chapter 8: Application Architecture
Application Architecture
Application Services
Application Clients
The Salient Points
Chapter 9: Common Problems for Teams Starting Out with Domain-Driven Design
Overemphasizing the Importance of Tactical Patterns
Missing the Real Value of DDD: Collaboration, Communication, and Context
Spending Too Much Time on What’s Not Important
Making Simple Problems Complex
Underestimating the Cost of Applying DDD
The Salient Points
Chapter 10: Applying the Principles, Practices, and Patterns of DDD
Selling DDD
Applying the Principles of DDD
Exploration and Experimentation
Making the Implicit Explicit
A Problem Solver First, A Technologist Second
How Do I Know That I Am Doing It Right?
The Salient Points
Part II: Strategic Patterns: Communicating Between Bounded Contexts
Chapter 11: Introduction to Bounded Context Integration
How to Integrate Bounded Contexts
Integrating Distributed Bounded Contexts
The Challenges of DDD with Distributed Systems
SOA and Reactive DDD
The Salient Points
Chapter 12: Integrating via Messaging
Messaging Fundamentals
Building an E-Commerce Application with NServiceBus
Maintaining a Messaging Application
Integrating a Bounded Context with Mass Transit
The Salient Points
Chapter 13: Integrating via HTTP with RPC and REST
Why Prefer HTTP?
RPC
REST
The Salient Points
Part III: Tactical Patterns: Creating Effective Domain Models
Chapter 14: Introducing the Domain Modeling Building Blocks
Tactical Patterns
Patterns to Model Your Domain
LifeCycle Patterns
Emerging Patterns
The Salient Points
Chapter 15: Value Objects
When to Use a Value Object
Defining Characteristics
Common Modeling Patterns
Persistence
The Salient Points
Chapter 16: Entities
Understanding Entities
Implementing Entities
Common Entity Modeling Principles and Patterns
The Salient Points
Chapter 17: Domain Services
Understanding Domain Services
Utilizing Domain Services
The Salient Points
Chapter 18: Domain Events
Essence of the Domain Events Pattern
Event Handling Actions
Domain Events’ Implementation Patterns
Testing Domain Events
The Salient Points
Chapter 19: Aggregates
Managing Complex Object Graphs
Aggregates
Defining Aggregate Boundaries
Implementing Aggregates
The Salient Points
Chapter 20: Factories
The Role of a Factory
The Salient Points
Chapter 21: Repositories
Repositories
A Misunderstood Pattern
Aggregate Persistence Strategies
A Repository Is an Explicit Contract
Transaction Management and Units of Work
To Save or Not To Save
The Repository as an Anticorruption Layer
Other Responsibilities of a Repository
Repository Antipatterns
Repository Implementations
The Salient Points
Chapter 22: Event Sourcing
The Limitations of Storing State as a Snapshot
Gaining Competitive Advantage by Storing State as a Stream of Events
Event-Sourced Aggregates
Building an Event Store
Using the Purpose-Built Event Store
CQRS with Event Sourcing
Recapping the Benefits of Event Sourcing
Weighing the Costs of Event Sourcing
Additional Learning Resources
The Salient Points
Part IV: Design Patterns for Effective Applications
Chapter 23: Architecting Application User Interfaces
Design Considerations
Example 1: An HTML API-Based, Server-Side UI for Nondistributed Bounded Contexts
Example 2: A Data API-Based, Client-Side UI for Distributed Bounded Contexts
The Salient Points
Chapter 24: CQRS: An Architecture of a Bounded Context
The Challenges of Maintaining a Single Model for Two Contexts
A Better Architecture for Complex Bounded Contexts
The Command Side: Business Tasks
The Query Side: Domain Reporting
The Misconceptions of CQRS
Patterns to Enable Your Application to Scale
The Salient Points
Chapter 25: Commands: Application Service Patterns for Processing Business Use Cases
Differentiating Application Logic and Domain Logic
Application Service Patterns
Testing Application Services
The Salient Points
Chapter 26: Queries: Domain Reporting
Domain Reporting Within a Bounded Context
Domain Reporting Across Bounded Contexts
The Salient Points
Title Page
Copyright
Dedication
About the Author
Credits
Acknowledgments
Advert
EULA
Search in book...
Toggle Font Controls
Playlists
Add To
Create new playlist
Name your new playlist
Playlist description (optional)
Cancel
Create playlist
Sign In
Email address
Password
Forgot Password?
Create account
Login
or
Continue with Facebook
Continue with Google
Sign Up
Full Name
Email address
Confirm Email Address
Password
Login
Create account
or
Continue with Facebook
Continue with Google
Prev
Previous Chapter
Patterns, Principles, and Practices of Domain-Driven Design
Next
Next Chapter
Introduction
CONTENTS
Introduction
Overview of the Book and Technology
How This Book Is Organized
Who Should Read This Book
Source Code
Errata
p2p.wrox.com
Summary
Part I: The Principles and Practices of Domain-Driven Design
Chapter 1: What Is Domain-Driven Design?
The Challenges of Creating Software for Complex Problem Domains
How the Patterns of Domain-Driven Design Manage Complexity
The Practices and Principles of Domain-Driven Design
Popular Misconceptions of Domain-Driven Design
The Salient Points
Chapter 2: Distilling the Problem Domain
Knowledge Crunching and Collaboration
Gaining Domain Insight with Domain Experts
Patterns for Effective Knowledge Crunching
Look For Existing Models
The Salient Points
Chapter 3: Focusing on the Core Domain
Why Decompose a Problem Domain?
How to Capture the Essence of the Problem
How to Focus on the Core Problem
How Subdomains Shape a Solution
Not All Parts of a System Will Be Well Designed
What If You Have No Core Domain?
The Salient Points
Chapter 4: Model-Driven Design
What Is a Domain Model?
Model-Driven Design
Using a Ubiquitous Language to Bind the Analysis to the Code Model
Collaborating on a Ubiquitous Language
How to Create Effective Domain Models
When to Apply Model-Driven Design
The Salient Points
Chapter 5: Domain Model Implementation Patterns
The Domain Layer
Domain Model Implementation Patterns
The Salient Points
Chapter 6: Maintaining the Integrity of Domain Models with Bounded Contexts
The Challenges of a Single Model
Use Bounded Contexts to Divide and Conquer a Large Model
Implementing Bounded Contexts
The Salient Points
Chapter 7: Context Mapping
A Reality Map
Recognising the Relationships between Bounded Contexts
Communicating the Context Map
The Strategic Importance of Context Maps
The Salient Points
Chapter 8: Application Architecture
Application Architecture
Application Services
Application Clients
The Salient Points
Chapter 9: Common Problems for Teams Starting Out with Domain-Driven Design
Overemphasizing the Importance of Tactical Patterns
Missing the Real Value of DDD: Collaboration, Communication, and Context
Spending Too Much Time on What’s Not Important
Making Simple Problems Complex
Underestimating the Cost of Applying DDD
The Salient Points
Chapter 10: Applying the Principles, Practices, and Patterns of DDD
Selling DDD
Applying the Principles of DDD
Exploration and Experimentation
Making the Implicit Explicit
A Problem Solver First, A Technologist Second
How Do I Know That I Am Doing It Right?
The Salient Points
Part II: Strategic Patterns: Communicating Between Bounded Contexts
Chapter 11: Introduction to Bounded Context Integration
How to Integrate Bounded Contexts
Integrating Distributed Bounded Contexts
The Challenges of DDD with Distributed Systems
SOA and Reactive DDD
The Salient Points
Chapter 12: Integrating via Messaging
Messaging Fundamentals
Building an E-Commerce Application with NServiceBus
Maintaining a Messaging Application
Integrating a Bounded Context with Mass Transit
The Salient Points
Chapter 13: Integrating via HTTP with RPC and REST
Why Prefer HTTP?
RPC
REST
The Salient Points
Part III: Tactical Patterns: Creating Effective Domain Models
Chapter 14: Introducing the Domain Modeling Building Blocks
Tactical Patterns
Patterns to Model Your Domain
LifeCycle Patterns
Emerging Patterns
The Salient Points
Chapter 15: Value Objects
When to Use a Value Object
Defining Characteristics
Common Modeling Patterns
Persistence
The Salient Points
Chapter 16: Entities
Understanding Entities
Implementing Entities
Common Entity Modeling Principles and Patterns
The Salient Points
Chapter 17: Domain Services
Understanding Domain Services
Utilizing Domain Services
The Salient Points
Chapter 18: Domain Events
Essence of the Domain Events Pattern
Event Handling Actions
Domain Events’ Implementation Patterns
Testing Domain Events
The Salient Points
Chapter 19: Aggregates
Managing Complex Object Graphs
Aggregates
Defining Aggregate Boundaries
Implementing Aggregates
The Salient Points
Chapter 20: Factories
The Role of a Factory
The Salient Points
Chapter 21: Repositories
Repositories
A Misunderstood Pattern
Aggregate Persistence Strategies
A Repository Is an Explicit Contract
Transaction Management and Units of Work
To Save or Not To Save
The Repository as an Anticorruption Layer
Other Responsibilities of a Repository
Repository Antipatterns
Repository Implementations
The Salient Points
Chapter 22: Event Sourcing
The Limitations of Storing State as a Snapshot
Gaining Competitive Advantage by Storing State as a Stream of Events
Event-Sourced Aggregates
Building an Event Store
Using the Purpose-Built Event Store
CQRS with Event Sourcing
Recapping the Benefits of Event Sourcing
Weighing the Costs of Event Sourcing
Additional Learning Resources
The Salient Points
Part IV: Design Patterns for Effective Applications
Chapter 23: Architecting Application User Interfaces
Design Considerations
Example 1: An HTML API-Based, Server-Side UI for Nondistributed Bounded Contexts
Example 2: A Data API-Based, Client-Side UI for Distributed Bounded Contexts
The Salient Points
Chapter 24: CQRS: An Architecture of a Bounded Context
The Challenges of Maintaining a Single Model for Two Contexts
A Better Architecture for Complex Bounded Contexts
The Command Side: Business Tasks
The Query Side: Domain Reporting
The Misconceptions of CQRS
Patterns to Enable Your Application to Scale
The Salient Points
Chapter 25: Commands: Application Service Patterns for Processing Business Use Cases
Differentiating Application Logic and Domain Logic
Application Service Patterns
Testing Application Services
The Salient Points
Chapter 26: Queries: Domain Reporting
Domain Reporting Within a Bounded Context
Domain Reporting Across Bounded Contexts
The Salient Points
Title Page
Copyright
Dedication
About the Author
Credits
Acknowledgments
Advert
EULA
List of Tables
Chapter 13
Table 13.1
Table 13.2
Chapter 22
Table 22.1
Table 22.2
Chapter 26
Table 26.1
Table 26.2
Table 26.3
List of Illustrations
Introduction
Figure I.1 A blueprint of the problem space of DDD.
Figure I.2 A blueprint of the solution space of Domain-Driven Design.
Chapter 1
Figure 1.1 Complexity in software.
Figure 1.2 Code rot.
Figure 1.3 Applying the strategic patterns of Domain-Driven Design.
Figure 1.4 DDD patterns that are applicable to the problem space.
Figure 1.5 DDD patterns that are applicable to the solution space.
Chapter 2
Figure 2.1 Knowledge crunching.
Figure 2.2 The roles of stakeholders, domain experts, and the development team.
Figure 2.3 An impact map.
Figure 2.4 A Business Model Canvas.
Chapter 3
Figure 3.1 Cuts of a pig.
Figure 3.2 The domain of an online auction site.
Figure 3.3 The domain of an online auction site distilled into subdomains.
Figure 3.4 The distilled domain of an online auction site partitioned into core, generic, and supporting domains.
Figure 3.5 How a solution maps to the subdomains of the auction system.
Figure 3.6 Dealing with legacy.
Chapter 4
Figure 4.1 The role of a domain model.
Figure 4.2 The domain versus the domain model.
Figure 4.3 The binding between the code and analysis model.
Figure 4.4 The problems with upfront design.
Figure 4.5 The code model and the analysis model are kept in synergy.
Figure 4.6 Team modeling.
Figure 4.7 Translation costs of the project.
Figure 4.8 London Tube map bearing little resemblance to the distance between stations.
Chapter 5
Figure 5.1 The code that represents the domain model makes up only a small portion of the overall codebase.
Figure 5.2 Multiple domain models implemented in various patterns inside an application.
Figure 5.3 The domain model pattern.
Figure 5.4 The domain model of an auction site.
Figure 5.5 The transaction script pattern.
Figure 5.6 The transaction script pattern UML.
Chapter 6
Figure 6.1 A model will grow in complexity.
Figure 6.2 Complexity in a model increases with multiple teams.
Figure 6.3 Domain terms mean different things in different contexts.
Figure 6.4 The same concept should be understood within different contexts.
Figure 6.5 A single view of an entity in the domain for all subdomains can quickly become a problem.
Figure 6.6 The product, an implementation of the god object antipattern.
Figure 6.7 The difference between an enterprise model and a domain model.
Figure 6.8 Putting terms into context and identifying multiple models.
Figure 6.9 Define each model within its own context.
Figure 6.10 A layered architecture pattern per bounded context and not per application.
Figure 6.11 The Product class in different contexts.
Figure 6.12 You can apply different architectural patterns to the different bounded contexts.
Figure 6.13 The anatomy of a bounded context.
Chapter 7
Figure 7.1 A context map.
Figure 7.2 The technical integration on a context map.
Figure 7.3 The organizational relationships on a context map.
Figure 7.4 Use an anticorruption layer to integrate with code you don’t own or can’t change.
Figure 7.5 Integration with a shared kernel.
Figure 7.6 Multiple subsystems integrating with similar transformation efforts.
Figure 7.7 Integration with an open host service.
Figure 7.8 A customer-supplier relationship between bounded contexts.
Figure 7.9 A context map showing the types of integration between bounded contexts.
Chapter 8
Figure 8.1 A layered architecture.
Figure 8.2 Dependency inversion within a layered architecture.
Figure 8.3 Domain objects are hidden from clients of the application.
Figure 8.4 Testing layers in isolation.
Figure 8.5 Bounded contexts integrating via a shared data schema.
Figure 8.6 Bounded contexts with their own data schema.
Figure 8.7 Bounded contexts integrating via a separate application layer.
Figure 8.8 Presentation layer composed of bounded contexts.
Figure 8.9 Application logic versus domain logic.
Figure 8.10 A view model mapping to many domain objects.
Figure 8.11 View models queried directly from the data source.
Figure 8.12 View store separated from transactional storage.
Figure 8.13 :Various clients of an application.
Figure 8.14 A system composed of multiple bounded contexts.
Figure 8.15 A process manager.
Chapter 10
Figure 10.1 The process of DDD.
Chapter 11
Figure 11.1 Multiple bounded contexts inside a single solution.
Figure 11.2 Multiple bounded contexts using a shared schema.
Figure 11.3 Autonomous bounded contexts with a shared-nothing architecture.
Figure 11.4 A bubble context.
Figure 11.5 An autonomous bubble context.
Figure 11.6 Exposing a legacy context as a JSON web service.
Figure 11.7 Database integration.
Figure 11.8 Flat file integration.
Figure 11.9 E-commerce system using synchronous RPC.
Figure 11.10 Replacing RPC with reactive.
Figure 11.11 Decomposing the shipping bounded context into business components.
Figure 11.12 Shipping bounded context broken down into business components and components.
Figure 11.13 Possible deployment view of components in the Shipping bounded context.
Figure 11.14 Sharing dependencies is only allowed between components inside the same business component.
Chapter 12
Figure 12.1 Message bus architecture.
Figure 12.2 Adding new event subscribers doesn’t affect existing code.
Figure 12.3 A component diagram showing domain events.
Figure 12.4 A containers diagram for a typical e-commerce application.
Figure 12.5 The basic web page for placing an order.
Figure 12.6 Creating an empty Visual Studio solution.
Figure 12.7 Adding the DDDesign.Web MVC 4 web application.
Figure 12.8 Selecting empty ASP.NET MVC template with the Razor view engine.
Figure 12.9 Adding a reference to the Sales.Messages project from the DDDesign.Web project.
Figure 12.10 Installing NServiceBus with the NuGet package manager console.
Figure 12.11 Adding the Orders controller.
Figure 12.12 Solution structure after adding Orders controller and view.
Figure 12.13 Selecting solution properties.
Figure 12.14 Configuring each project to start up.
Figure 12.15 An NServiceBus server setting up an application.
Figure 12.16 Adding the OrderCreated event to the Sales.Messages project.
Figure 12.17 Adding the two messages to the Billing.Messages project.
Figure 12.18 Setting all your NServiceBus servers to start up.
Figure 12.19 Looks like the payment was processed successfully.
Figure 12.20 Actually, the payment failed twice first.
Figure 12.21 The payment rejected use case.
Figure 12.22 Multiple bounded contexts store the same piece of data locally.
Figure 12.23 Shipping bounded context storing data locally and using it to arrange shipping.
Figure 12.24 Business components have their own APIs.
Figure 12.25 Pages get their data from multiple APIs.
Figure 12.26 Locating the error queue in Visual Studio’s Server Explorer.
Figure 12.27 Viewing the contents of a message in the error queue.
Figure 12.28 Promotions bounded context integrating into e-commerce messaging system.
Figure 12.29 A messaging bridge is like a link.
Figure 12.30 Mass Transit receiving messages via the bridge.
Chapter 13
Figure 13.1 The “find recommended users” use case.
Figure 13.2 Adding the Account Management WCF Service.
Figure 13.3 Visual Studio’s WCF test client.
Figure 13.4 Invoking an RPC in WCF’s test client.
Figure 13.5 Adding a Service Reference in Visual Studio.
Figure 13.6 Generated proxy classes.
Figure 13.7 The RPC must have occurred.
Figure 13.8 Viewing the output of a Web API controller in a browser.
Figure 13.9 Component diagram for the Recommended Accounts use case.
Figure 13.10 Containers diagram of Discovery, Account Management, and Marketing bounded contexts.
Figure 13.11 Flow of HTTP requests for the Add Follower use case.
Figure 13.12 Flow of HTTP requests for polling and consuming the Began Following event feed.
Figure 13.13 Accessing the HAL browser.
Figure 13.14 Viewing the entry point resource in the HAL browser.
Figure 13.15 Following the Accounts link in the HAL browser.
Figure 13.16 Resource’s data fields are represented as plain JSON.
Figure 13.17 The Event Store’s admin UI.
Figure 13.18 The NON-GET button in the HAL browser.
Figure 13.19 Constructing JSON on the NON-GET dialog in the HAL browser.
Figure 13.20 Viewing an event in the Event Store.
Figure 13.21 Feed consumer processing events
Chapter 14
Figure 14.1 Tactical patterns—domain model building blocks.
Figure 14.2 An entity.
Figure 14.3 A value object.
Figure 14.4 Modules used to organize domain concepts within a domain model.
Figure 14.5 A large object graph.
Figure 14.6 A large object graph split into aggregates.
Figure 14.7 An aggregate root acts as the entry point to the aggregate.
Figure 14.8 Aggregates should be based around invariants.
Figure 14.9 An aggregate root acts as the entry point to the aggregate.
Figure 14.10 A factory.
Figure 14.11 A repository.
Figure 14.12 A domain event.
Figure 14.13 Storing events, not snapshots
Chapter 15
Figure 15.1 Value object stored in custom format.
Figure 15.2 Separate table for Customer and Name.
Figure 15.3 Customer foreign key used to join Customer and Name.
Chapter 16
Figure 16.1 Creating a client-side GUID and posting to multiple back-end services.
Chapter 18
Figure 18.1 Ensuring correct transactional behavior
Figure 18.2 Flow of internal and external events in a typical business use case
Chapter 19
Figure 19.1 Complexity-causing bidirectional relationships.
Figure 19.2 Constraining a bidirectional association.
Figure 19.3 Qualifying associations.
Figure 19.4 Qualifying associations with filter criteria from the Ubiquitous Language (UL).
Figure 19.5 Modeling relationships with object references increases complexity.
Figure 19.6 Simplified relationships using IDs instead of object references.
Figure 19.7 Complex domain model with an abundance of unnecessary associations.
Figure 19.8 Clearer domain model based only on essential associations.
Figure 19.9 Locking caused by large transactional boundary.
Figure 19.10 Inconsistent data arising from lack of transactional boundaries.
Figure 19.11 Aligning transactional boundaries with domain invariants.
Figure 19.12 Enforcing consistency with help from aggregate roots.
Figure 19.13 Aggregates are eventually consistent externally.
Figure 19.14 Eventually consistent Loyalty aggregate.
Figure 19.15 eBidder bounded contexts.
Figure 19.16 Listing bounded context aggregates.
Figure 19.17 Question aggregate boundary definition.
Figure 19.18 Auction aggregate boundary definition.
Figure 19.19 Listing aggregate boundary definition.
Figure 19.20 All aggregate boundary definitions.
Figure 19.21 Aligning aggregates with transactional boundaries.
Figure 19.22 Aggregate roots are the gateway into an aggregate.
Figure 19.23 Aggregate roots have global identity.
Figure 19.24 Consumers of an aggregate may not hold a reference to the aggregate’s internal members.
Figure 19.25 Sharing information between aggregates by using copies of internal objects.
Figure 19.26 Non aggregate roots can hold a reference to roots from other aggregates.
Figure 19.27 Aggregates should be loaded from a database entirely to protect their integrity.
Figure 19.28 Loading aggregates versus going directly to the database.
Figure 19.29 Aggregate boundaries are consistency boundaries.
Figure 19.30 Eventual consistency using database integration.
Chapter 21
Figure 21.1 An ORM maps between the domain and persistence model.
Figure 21.2 An ORM maps between the domain and the persistence model.
Figure 21.3 An aggregate can be serialized and stored.
Figure 21.4 The memento pattern enables you to map a snapshot of the domain model to the persistence model.
Figure 21.5 Save the events that have occurred to an aggregate.
Figure 21.6 The unit-of-work pattern.
Figure 21.7 The repository acts as an anticorruption layer.
Figure 21.8 Solution object model.
Figure 21.9 Visual Solution project structure
Figure 21.10 NuGet Package Manager
Figure 21.11 The Visual Studio solution structure
Figure 21.12 The build action property of the XML Mapping file
Figure 21.13 The database schema
Figure 21.14 The running program
Figure 21.15 Install RavenDB client libraries via NuGet.
Figure 21.16 Solution explorer with an application based on the NHibernate sample.
Figure 21.17 Inspecting the document inside RavenDB Management Studio.
Figure 21.18 Install Entity Framework client libraries via NuGet.
Figure 21.19 Solution explorer with an application based on the NHibernate sample.
Figure 21.20 Install Dapper client libraries via NuGet.
Figure 21.21 Skeleton solution based on the Entity Framework solution.
Figure 21.22 Add a reference to System.Configuration.
Figure 21.23 Add a reference to System.Transactions.
Chapter 22
Figure 22.1 Calculating the state for any point in history by replaying events.
Figure 22.2 Creating projections from multiple event streams.
Figure 22.3 Efficiently restoring state by using snapshots.
Figure 22.4 Event Store’s stream tab indicating the test data was successfully inserted.
Figure 22.5 Result of running a query in the Event Store web UI.
Figure 22.6 Creating a projection in the web UI.
Figure 22.7 One event stream used to support many different queries and use cases.
Figure 22.8 Creating materialized/denormalized views of the event stream to support each use case.
Chapter 23
Figure 23.1 UI for autonomous applications.
Figure 23.2 UI that defers to authority.
Figure 23.3 Composing a web page with HTML provided by bounded contexts.
Figure 23.4 Pulling in data from multiple bounded contexts.
Figure 23.5 Aggregating on the client.
Figure 23.6 Aggregating on the server.
Figure 23.7 The design for this example.
Figure 23.8 Rendering of composite UI.
Figure 23.9 The design for this example.
Figure 23.10 Client-side JSON API composition in action.
Chapter 24
Figure 24.1 A single model fulfilling the read and write sides of an application.
Figure 24.2 The CQRS pattern with a separate read and write model.
Figure 24.3 The command side of CQRS.
Figure 24.4 A user interface pulling data from many aggregates.
Figure 24.5 The query side of CQRS.
Figure 24.6 Using a different data store for querying.
Figure 24.7 An eventually-consistent read model.
Figure 24.8 Consolidate data from many bounded contexts into a single read model.
Figure 24.9 Use a copy of the transactional database for the read model.
Figure 24.10 An asynchronous write side.
Figure 24.11 Scaling out the read and write sides of CQRS.
Chapter 25
Figure 25.1 Where application services fit in.
Figure 25.2 The Recommend-a-Friend use case.
Figure 25.3 Transactional boundary for Recommend-a-Friend.
Chapter 26
Figure 26.1 Denormalized view cache for the loyalty report.
Figure 26.2 Projecting the “diagnoses” event stream onto event streams representing the monthly summary of each diagnosis.
Figure 26.3 Aggregating data from multiple bounded contexts into a single report.
Figure 26.4 Standard reporting context.
Figure 26.5 Complex data-processing reporting context.
Guide
Cover
Table of Contents
Part I
Pages
xxxv
xxxvi
xxxvii
xxxviii
xxxix
xl
xli
xlii
xliii
1
3
4
5
6
7
8
9
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
73
74
75
76
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
105
106
107
108
109
111
112
113
114
115
116
117
118
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
222
223
224
225
226
227
228
229
231
232
233
234
235
236
237
238
239
240
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
283
284
285
286
287
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
307
309
310
311
312
313
314
315
317
318
320
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
361
362
363
364
365
366
367
368
369
371
372
373
374
375
376
377
378
379
380
381
382
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
439
440
441
442
443
444
446
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
519
520
521
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
543
544
545
546
547
548
550
551
552
553
554
555
556
557
558
559
561
562
563
564
565
566
567
568
569
570
571
572
574
575
576
577
578
579
580
581
582
583
584
585
588
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
631
632
633
634
635
636
637
638
639
640
641
642
643
645
646
647
648
649
651
652
653
654
655
656
658
659
660
661
662
663
664
665
666
667
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
746
747
Add Highlight
No Comment
..................Content has been hidden....................
You can't read the all page of ebook, please click
here
login for view all page.
Day Mode
Cloud Mode
Night Mode
Reset