--- PDF page 325 / printed index page 299 ---
Index
A
accidental complexity
case study of applying DDD, 283
growth and, 180, 181, 182
active records, 69-71
design evolving
active record to domain model, 174
transaction script to active record, 174
design heuristics, 161, 163
Fowler naming, 71
implementation, 70
layered architecture, 124
when to use, 71
aggregates, 84-92
about, 88
boundaries, 227
case study of applying DDD
customer relationship management
bounded context, 276-279
marketing bounded context, 275
commands, 85
communication
aggregate root, 90
domain events, 91, 143-154
outbox pattern, 145
process manager, 150-154
saga pattern, 147-150
complexity reduction, 95
consistency and aggregate boundaries, 150
consistency enforcement, 84-87
domain services coordinating, 92
“Effective Aggregate Design” (Vernon), 277
entities, 84
identification field, 84, 114
EventStorming, 194
growth management, 182
hierarchy of entities, 87-89
microservices, 227
referencing other aggregates, 89
state persisted versus event sourcing, 99, 108
(see also domain model; event-sourced
domain model)
Ticket aggregate (see help desk)
transaction boundary, 87
domain services and, 93
ubiquitous language, 92
Agile Manifesto, 30
analysis model, 23
analytical data management platforms
about, 254
analytical versus transactional model, 249
data lake, 257-258
challenges of, 258
data mesh
about, 259
data as product, 261, 262
decomposing data around domains, 259
domain-driven design and, 263
governance ecosystem, 262
data warehouse, 254-256
challenges of, 258
analyzing business domains (see domain analy‐
sis)
anemic domain model antipattern, 71, 275
(see also active records)
answers to exercise questions, 289-295
anticorruption layer, 54
microservices, 230
299

--- PDF page 326 / printed index page 300 ---
model translation, 137-140
modernization strategy, 206
APIs in application layer, 86
application layer, 86, 126
(see also service layer)
applying domain-driven design (see case study
of applying DDD)
architecture (see software architecture)
audit log
event sourcing for, 111
text file instead, 114
monetary transactions, 162
B
backend-for-frontend pattern, 142
big ball of mud, 180
(see also real-world domain-driven design)
distributing via events, 241
The Blue Book (Evans), xiii
book source code, xix
book website, xix
boundaries
about, 41, 49
aggregates, 227
case study discussion, 286
event-driven architecture, 241
growth management, 180
logical boundaries, 41
layers in layered architecture, 125
service layer as, 122
microservices
about, 225
aggregates, 227
bounded contexts, 225-227
subdomains, 228
modernization strategy, 205
ownership boundaries, 42
physical boundaries, 41
bounded contexts, 225
microservices, 223, 225
tiers in N-Tier architecture, 125
real-world DDD, 203
bounded contexts
about, 35
boundaries (see boundaries)
case study of applying DDD
bonuses, 280
boundaries discussion, 286
business domain, 273-275
customer relationship management,
276-279
event crunchers, 279
marketing, 275
marketing hub, 282
communication, 137-142
context map, 57-58
limitations, 58
maintenance, 58
data mesh architecture, 263
design heuristics, 160
EventStorming, 194
growth management, 181
integrating
about contracts, 49
cooperation, 50-52
customer–supplier, 53-55
separate ways no collaboration, 56
microservices, 225-227
model boundaries, 36
organizational changes and, 178
real life, 42-46
day-to-day DDD, 212
scope of, 37
strangler migration pattern, 207-210
subdomains versus, 38-41
interplay between, 39-41
subdomain design changes and, 172
ubiquitous language, 35-38
(see also ubiquitous language)
Box, George, 28
brainstorming (see EventStorming)
Brandolini, Alberto, 21, 22, 186, 195, 197
Brooks, Fred, 99
brownfield DDD, 201
(see also real-world domain-driven design)
business domains
about, 3
need to know, 3, 267
about domain-driven design, xvi
analyzing (see domain analysis)
bounded contexts in real life, 42-46
case study of applying DDD, 273-275
real-world DDD, 202
bounded contexts integrated
about contracts, 49
cooperation, 50-52
customer–supplier, 53-55
separate ways no collaboration, 56
300 
| 
Index

--- PDF page 327 / printed index page 301 ---
business logic in layered architecture, xv
EventStorming for knowledge, 207
(see also EventStorming)
modeling (see modeling business domain)
subdomains, 228
(see also subdomains)
case study discussion, 284-286
(see also case study of applying
DDD)
ubiquitous language for, 24-26
case study of applying DDD, 275, 278,
281
modernization strategy, 207
business knowledge
business problems, 21, 267
communication, 22-24
analysis model, 23
ubiquitous language, 24-26
(see also ubiquitous language)
domain experts, xiii, 17
(see also domain experts)
EventStorming for, 207
(see also EventStorming)
knowledge discovery, 22
knowledge lost, 179, 204
modeling, 27
(see also modeling business domain)
real-world DDD, 202
business logic implementation
about, 63
active records, 69-71
design heuristics, 161
Fowler naming, 71
implementation, 70
layered architecture, 124
when to use, 71
brainstorming (see EventStorming)
case study (see case study of applying DDD)
design heuristics, 161-163
changes in design, 169-172
domain model pattern
about, 76
about history, 75
aggregates, 84-92, 95
complexity management, 77, 94
design heuristics, 162
domain services, 92
entities, 83
implementation, 77
layered architecture and, 125
value objects, 77-83, 95
pragmatic approach, 72
real-world DDD, 202
modernization strategy, 204-210
software architecture
business logic versus, 117
command-query responsibility segrega‐
tion, 128-134
dependency inversion principle, 126
ports & adapters architecture, 125, 127
service layer for business logic, 122, 126
time dimension (see event-sourced domain
model)
transaction scripts, 63-69
debugging, 64-68
design heuristics, 161
implementation, 64
layered architecture, 124
when to use, 68
business logic layer of layered architecture, 119
business problems, 21, 267
C
case study of applying DDD
about, 273
bounded contexts
bonuses, 280
business domain, 273-275
customer relationship management,
276-279
event crunchers, 279
marketing, 275
marketing hub, 282
discussion
boundaries of bounded contexts, 286
subdomains, 284-286
ubiquitous language, 283
ubiquitous language
discussion, 283
domain experts, 275, 281
two separate languages, 278
The Choice (Goldratt), 94
collaboration patterns
about, 49
cooperation, 50-52
partnerships, 50
shared kernel, 50-52
customer–supplier
Index 
| 
301

--- PDF page 328 / printed index page 302 ---
about, 53
anticorruption layer, 54
conformist, 53
open-host service, 55
subdomain changes affecting, 173
modernization strategy, 206
organizational changes
customer–supplier to separate ways, 179
partnership to customer–supplier, 179
separate ways no collaboration, 56
communication issues, 56
generic subdomains, 56
model differences, 56
subdomain changes affecting, 173
command-query responsibility segregation
(CQRS), 128-134
data mesh architecture, 263
implementation, 129
command execution model, 129
read models, 130
model segregation, 133
polyglot modeling, 129
projecting read models, 130
asynchronous projections, 132
challenges, 132
synchronous projections, 130
when to use, 133
design heuristics, 163
commands
aggregate state-modifying methods, 85
events versus, 234
EventStorming, 190
saga pattern of aggregate communication,
147-150
process manager versus, 150
communication
about domain-driven design, xxiv
aggregates
aggregate root, 90
domain events, 91, 143-154
outbox pattern, 145
process manager, 150-154
saga pattern, 147-150
business knowledge, 22-24
analysis model, 23
case study of applying DDD, 275, 281
EventStorming for, 207
(see also EventStorming)
ubiquitous language, 24-26
(see also ubiquitous language)
case study of applying DDD
discussion, 283
two separate languages, 278
ubiquitous language, 275, 281
collaboration obstacle, 56, 278
context map for patterns, 57, 206
event-driven architecture as, 234
domain events, 239
event notification, 236
event-carried state transfer, 237
layers in layered architecture, 120
model translation
about, 137
stateful, 141
stateful aggregating incoming data, 141
stateful unifying multiple sources, 142
stateless, 138
stateless asynchronous, 140
stateless synchronous, 138
modeling business domain, 28
(see also ubiquitous language)
non-English-speaking countries, 31
services, 218
software crisis and, xxiv
competitive advantage
core subdomains providing, 5, 7
in-house implementation, 10
generic subdomains not providing, 6, 7
subdomain comparisons, 7
supporting subdomains not providing, 6, 7
complexity
about, 7, 8
accidental complexity
case study of applying DDD, 283
growth and, 180, 181, 182
business logic domain model, 77, 94
core subdomains, 5, 8
software design affected, 8
domain complexity
about, 33
boundaries, 41
bounded contexts, 35-38
bounded contexts in real life, 42-46
inconsistent models, 33-35
subdomains versus bounded contexts, 38
generic subdomains, 6, 8
global complexity, 221
302 
| 
Index

--- PDF page 329 / printed index page 303 ---
growth and accidental complexity, 180, 181,
182
subdomain comparisons, 7
system complexity
definition, 94
microservices and, 221-224
system definition, 221
compliance with GDPR and data deletion, 114
Composite/Structured Design (Myers), 221
conformist relationship, 53
context map of bounded contexts, 57-58
communication patterns, 57, 206
limitations, 58
maintenance, 58
contracts in bounded contexts
about, 49
communication, 137
cooperation, 50-52
partnerships, 50
shared kernel, 50-52
customer–supplier, 53-55
separate ways no collaboration, 56
cooperation pattern of bounded contexts, 50-52
partnerships, 50
shared kernel, 50-52
core domains versus core subdomains, 6
core subdomains, 4, 169
boundaries, 12
competitive advantage from, 5, 7
in-house implementation, 10
complexity, 5, 8
software design affected, 8
core domains versus, 6
design evolving
changing to generic, 170
changing to supporting, 172
generic changing to, 170
supporting changing to, 171
design heuristics, 162
evolving continuously, 9, 10
in-house implementation, 10
insights from event sourcing, 111
real-world DDD, 202
CRUD (create, read, update, and delete), 7
customer–supplier collaboration pattern
about, 53
anticorruption layer, 54
changing to separate ways, 179
conformist, 53
modernization strategy, 206
open-host service, 55
partnership changing to, 179
subdomain changes affecting, 173
D
data access layer of layered architecture, 119
infrastructure layer, 126
data corruption
aggregate consistency enforcement, 84-87
pragmatic approach, 72
transaction script errors, 64-68
data lake, 257-258
challenges of, 258
data as product, 261
data mesh
about, 249, 259
analytical data management platforms
about, 254
challenges of data lake and warehouse,
258
data lake, 257-258
data warehouse, 254-256
analytical versus transactional data model
about, 249
analytical models, 253
dimension table, 252
fact tables, 250-252
snowflake schema, 253
star schema, 253
data as product, 261
autonomy enabled, 262
decomposing data around domains, 259
domain-driven design and, 263
governance ecosystem, 262
online analytical processing data, 249
data polyglot persistence model, 129
data protection regulation
deleting data, 114
monetary transactions, 162
data warehouse (DWH), 254-256
challenges of, 258
DDD (see domain-driven design)
debugging
retroactive via event sourcing, 111
transaction script errors, 64-68
decision tree for tactical design, 166
deep modules
microservices as deep modules, 223
Index 
| 
303

--- PDF page 330 / printed index page 304 ---
modules in software system, 222
subdomains as deep modules, 229
degrees of freedom and complexity, 94
dependency inversion principle (DIP) , 126
design
changes in design
about, 169
active record to domain model, 174
case study discussion, 284, 286
domain knowledge, 179
domain model to event-sourced domain
model, 176
domains changed, 169-172
generating past transitions, 176
growth, 180-182
modeling migration events, 177
organizational changes, 178
strategic design concerns, 172
tactical design concerns, 173-178
transaction script to active record, 174
heuristics
about heuristics, 159
architectural patterns, 163
bounded contexts, 160
business logic implementation, 161-163
decision tree, 166
testing strategy, 164
strategic (see strategic design)
tactical (see tactical design)
Dijkstra, Edsger W., 28
dimension of time (see time modeled)
dimension table, 252
domain analysis
about business domains, 3
need to know, 3
business problem domains, 22
domain experts, xiii, 17
(see also domain experts)
examples
about, 14
BusVNext, 15
Gigmaster, 14-15
real-world DDD, 202
subdomain boundaries
about, 11
details of business functions, 11
essentials only, 14
subdomains as use cases, 12
subdomain types
about, 4, 11
core subdomains, 4
generic subdomains, 6
supporting subdomains, 6
supporting subdomains example, 6
subdomains compared
about, 7, 11
competitive advantage, 7
complexity, 7
in-house versus outsource, 10
volatility, 9
domain events
aggregate communication, 91, 143-154
outbox pattern, 145
process manager, 150-154
saga pattern, 147-150
brainstorming business processes, 185
(see also EventStorming)
event-driven architecture, 239
event notification versus, 239
event-carried state transfer versus, 240
example, 240
domain experts, 17
business knowledge
analysis model, 23
business problems, 21
data mesh architecture, 263
knowledge contribution, xiii, 17
knowledge discovery, 22
knowledge lost, 179, 204
sharing via EventStorming, 185
(see also EventStorming)
ubiquitous language, 24-26
case study ubiquitous language, 275, 281
domain complexity
about, 33
boundaries, 41
bounded contexts, 35-38
bounded contexts in real life, 42-46
inconsistent models, 33-35
subdomains versus bounded contexts, 38
modeling business domain, 22, 28
challenges, 30
tools, 29
domain knowledge (see domain experts)
domain model for business logic
about, 76
about history, 75
anemic domain model antipattern, 71, 275
304 
| 
Index

--- PDF page 331 / printed index page 305 ---
building blocks
aggregates, 84-92, 95
domain services, 92
entities, 83
value objects, 77-83, 95
design evolving, 169-172
active record to domain model, 174
domain model to event-sourced domain
model, 176
design heuristics, 162, 163
event-sourced domain model versus, 99,
108
implementation, 77
layered architecture and, 125
time modeled (see event-sourced domain
model)
domain services as business logic building
block, 92
domain-driven design (DDD)
about, xiii, xvi
strategic and tactical design, 1
(see also strategic design; tactical
design)
about communication, xxiv
(see also communication)
about problem–solution–implementation,
267-269
case study, 273
(see also case study of applying DDD)
data mesh and, 263
(see also data mesh)
domain experts, xiii, 17
(see also domain experts)
further reading, 269-271
real-world DDD, 201
(see also real-world domain-driven
design)
selling to team and management, 211-213
ubiquitous language, 24-26
(see also ubiquitous language)
Domain-Driven Design (Evans), xiii, xv, 6, 75,
274
E
“Effective Aggregate Design” (Vernon), 277
encryption of sensitive information, 114
entities, 83
aggregates, 84-92
about, 88
aggregate root, 90
commands, 85
consistency enforcement, 84-87
domain events, 91
hierarchy of entities, 87-89
referencing other aggregates, 89
transaction boundary, 87
identification fields, 83
aggregates, 84, 114
entry barriers of core subdomains, 5
ETL (extract, transform, load)
data lake architecture, 257-258
data warehouse architecture, 254-256
OLAP–OLTP coupling, 256
transaction scripts, 68
Evans, Eric, xiii, xv, 6, 75, 92, 205, 274
event notification, 236
concurrency, 237
domain events versus, 239
example, 240
security, 237
event-carried state transfer (ECST), 237
domain events versus, 240
example, 240
event-driven architecture (EDA)
about domain-driven design and, 233
about event-driven architecture, 233
event sourcing versus, 234
designing
about, 241
distributed big ball of mud, 241
implementation coupling, 243
logical coupling, 243
public and private events, 245
refactoring, 243
temporal coupling, 242
events, 234-241
event-sourced domain model, 108-110
about, 99
name, 110
advantages, 110
command-query responsibility segregation
pattern, 129, 134
design heuristics, 162, 163
disadvantages, 111
domain model changing to, 176
domain model versus, 99, 108
event sourcing pattern, 99-108
adjusting event schema, 112
Index 
| 
305

--- PDF page 332 / printed index page 306 ---
analysis, 105
event store, 107, 114
event-driven architecture versus, 234
searching earlier information values, 104
source of truth, 107, 115
version field for modification state, 104
forgettable payload pattern, 114
frequently asked questions
appending logs to log table, 115
audit log from text file, 114
deleting data, 114
performance, 112
scalability, 114
state-based source of truth, 115
historical perspectives
aggregate past states reconstituted, 111
generating past transitions, 176
retroactive debugging, 111
searching earlier information values, 104
selling domain-driven design, 213
snapshotting an aggregate’s events, 113
events
about, 234
about types of, 236
example, 240
domain events, 239
aggregates, 91
event notification versus, 239
event-carried state transfer versus, 240
example, 240
message translation and, 140
event notification, 236
concurrency, 237
domain events versus, 239
example, 240
security, 237
event-carried state transfer, 237
domain events versus, 240
example, 240
event-driven architecture, 234-241
event sourcing versus, 234
modeling migration events, 177
names of, 235
public and private, 245
structure, 235
EventStorming
about, 185
facilitation tips, 196
further reading, 271
modernization strategy, 207
process, 187-194
about how, 196
aggregates, 194
bounded contexts, 194
commands, 190
external systems, 193
pain points, 189
pivotal events, 190
policies, 191
read models, 192
timelines, 188
unstructured exploration, 187
remote EventStorming, 197
scope, 185
variants, 195
what is needed, 186
when to use, 196
who should participate, 186
exercise question answers, 289-295
external systems, 193
extract-transform-load operations (see ETL)
F
façade pattern abstraction layer
service layer for business logic layer,
121-122, 126
strangler migration pattern and, 208
fact tables, 250-252
forgettable payload pattern, 114
Fowler, Martin, 63, 69, 71, 75, 121
further reading, 269-271
G
GDPR (General Data Protection Regulation)
and data deletion, 114
generic subdomains, 6, 169
boundaries, 12
competitive advantage not provided, 6, 7
complexity, 6, 8
design evolving
changing to core, 170
changing to supporting, 172
core changing to, 170
supporting changing to, 171
design heuristics, 161
duplication over cooperation, 56
off-the-shelf or open source, 10
real-world DDD, 203
306 
| 
Index

--- PDF page 333 / printed index page 307 ---
Gherkin tests, 29
global complexity, 221
glossary for ubiquitous language, 29
Goldratt, Eliyahu M., xvi, 94
Goldratt-Ashlag, Efrat, 1, 267
Google Search domains, 5
Grove, Andrew, 245
growth management, 180-182
accidental complexity, 180, 181, 182
aggregates, 182
bounded contexts, 181
subdomains, 180
H
help desk
domain model of implementation
about, 76
aggregates, 84-92
entities, 83
value objects, 77-83
event-sourced domain model, 108-110
WolfDesk overview, xviii
heuristics defined, 159
historical perspectives via event sourcing
aggregate past states reconstituted, 111
generating past transitions, 176
retroactive debugging, 111
searching earlier information values, 104
version field for modification state, 104
I
identification fields
entities, 83
aggregates, 84, 114
forgettable payload pattern, 114
implementation of subdomains, 10
infrastructure layer of layered architecture, 126
dependency inversion principle, 126
ports & adapters architecture, 127
K
knowledge of business (see business knowl‐
edge)
L
layered architecture pattern, 118
about, xv
business logic layer, 119
communication between layers, 120
data access layer, 119
infrastructure layer, 126
dependency inversion principle, 126
infrastructure layer, 126
presentation layer, 118
infrastructure layer, 126
service layer, 121-124
terminology, 124
tiers versus layers, 125
when to use, 124
local complexity, 221
logical boundaries, 41
layers in layered architecture, 125
service layer as, 122
M
Malan, Ruth, 41
methods
commands of aggregates, 85
communication of result, 67
CRUD operations, 70
microservices
about microservices, 218
deep modules, 223
deep services, 222
design goal, 220
history, 217
naïve decomposition, 219
system complexity, 221-224
about services, 217
anticorruption layer, 230
boundaries
about, 225
aggregates, 227
bounded contexts, 225-227
subdomains, 228
case study of applying DDD, 282
open-host service, 229
system definition, 221
modeling business domain
about, 28
about models, 27
analysis model, 23
bounded contexts, 36, 41, 49
logical boundaries, 41
ownership boundaries, 42
physical boundaries, 41
scope of, 37, 51
Index 
| 
307

--- PDF page 334 / printed index page 308 ---
subdomains versus, 38-41
bounded contexts integrated
about contracts, 49
cooperation, 50-52
customer–supplier, 53-55
duplication over collaboration, 56
separate ways no collaboration, 56
brainstorming (see EventStorming)
command-query responsibility segregation,
129
domain expert thinking, 28
domain experts’ mental models, 22
(see also domain experts)
effective modeling, 28
inconsistent models, 33-35
polyglot modeling, 129
time modeled (see event-sourced domain
model)
ubiquitous language, 24-26
about modeling business domain, 28
challenges, 30
continuous effort, 29
modernization strategy, 207
non-English-speaking countries, 31
tools, 29
modernization strategy
about, 204
further reading, 270
refactoring, 210
strangler migration pattern, 207-210
strategic modernization, 205
context map, 206
tactical modernization, 207
ubiquitous language cultivated, 207
modules in software system, 222
microservices as deep modules, 223
subdomains as deep modules, 229
Myers, Glenford J., 221
N
N-Tier architecture versus layered, 125
names
aggregates and data members, 92
domain events, 91
events as past tense, 235
facts, 250
O
online analytical processing (OLAP) data, 249
(see also data mesh)
analytical versus transactional data model,
249
analytical models, 253
fact tables, 250-252
snowflake schema, 253
star schema, 253
dimension table, 252
ETL processes creating OLTP coupling, 256
online transactional processing (OLTP) data,
249
analytical versus transactional data model,
249
ETL processes creating OLAP coupling, 256
open-host service, 55
data mesh architecture, 263
microservices, 229
model translation, 137-138
modernization strategy, 207
optimistic concurrency and event sourcing, 111
organizational changes, 178
customer–supplier to separate ways, 179
partnership to customer–supplier, 179
Ousterhout, John, 222
outbox pattern of communication, 145
ownership boundaries, 42
data lake and warehouse architectures, 259
data mesh architecture, 259
P
parameter objects, 85
partnerships in bounded contexts, 50
partnership changing to customer–supplier,
179
Patterns of Enterprise Application Architecture
(Fowler), 71, 75, 121
performance of event sourcing pattern, 112
snapshotting an aggregate’s events, 113
The Philosophy of Software Design (Ousterh‐
out), 222
physical boundaries, 41
bounded contexts, 225
microservices, 223, 225
policies triggering command execution, 191
polyglot modeling, 129
data as product, 261
polyglot persistence, 129
ports & adapters architecture
about, 125, 127
308 
| 
Index

--- PDF page 335 / printed index page 309 ---
dependency inversion principle, 126
design heuristics, 163
infrastructure integration, 127
terminology, 126
variants, 128
when to use, 128
power differences in relationships
about, 53
anticorruption layer, 54
conformist, 53
open-host service, 55
pragmatic domain-driven design, 210
presentation layer of layered architecture, 118
infrastructure layer, 126
process manager pattern of aggregate commu‐
nication, 150-154
properties described by value objects, 84
protocols exposed for public, 55
published language public protocol, 55
R
read models
command-query responsibility segregation
asynchronous projections, 132
asynchronous projections challenges,
132
implementation, 130
projecting, 130
synchronous projections, 130
EventStorming, 192
reading further, 269-271
real-world domain-driven design
about, 201
big ball of mud, 180
bounded contexts in real life, 42-46
day-to-day DDD, 212
case study, 273
(see also case study of applying DDD)
day-to-day DDD, 211-213
modernization strategy
about, 204
context map, 206
further reading, 270
refactoring, 210
strangler migration pattern, 207-210
strategic modernization, 205
tactical modernization, 207
ubiquitous language cultivated, 207
pragmatic domain-driven design, 210
selling domain-driven design, 211-213
strategic analysis
business domain knowledge, 202
current system design, 203
refactoring modernization strategy, 210
event-driven architecture, 243
refrigerator-buying bounded contexts, 44
resources
book source code, xix
book website, xix
Domain-Driven Design (Evans), xiii, xv, 6,
75, 274
further reading, 269-271
Patterns of Enterprise Application Architec‐
ture (Fowler), 71, 75, 121
S
saga pattern of aggregate communication,
147-150
about sagas, 147
example, 147-150
sales leads via event sourcing, 99-108
analysis, 105
searching earlier information values, 104
version field for modification state, 104
scalability of event sourcing, 114
science bounded contexts, 43
scripts for transactions, 63-69
debugging, 64-68
implementation, 64
when to use, 68
semantic domains, 43
separate ways no collaboration pattern, 56
communication issues, 56
customer–supplier changing to, 179
generic subdomains, 56
model differences, 56
modernization strategy, 207
subdomain changes affecting, 173
service layer, 121-124
business logic implementation, 122, 126
public API actions to domain model, 86
shared kernel in bounded contexts, 50
communication via model translation, 137
implementation, 51
shared scope, 51
when to use, 52
Shoup, Randy, 218
snapshotting an aggregate’s events, 113
Index 
| 
309

--- PDF page 336 / printed index page 310 ---
snowflake schema, 253
software architecture
about domain-driven design, xvi, 134
about patterns, 117
boundaries, 41
business logic versus, 117
command-query responsibility segregation,
128-134
challenges, 132
command execution model, 129
data mesh architecture, 263
implementation, 129
model segregation, 133
polyglot modeling, 129
projecting read models, 130-133
read models, 130
when to use, 133, 163
dependency inversion principle, 126
design heuristics, 163
further reading, 270
layered architecture pattern, 118
about, xv
business logic layer, 119
communication between layers, 120
data access layer, 119
dependency inversion principle, 126
infrastructure layer, 126
presentation layer, 118
service layer, 121-124
terminology, 124
tiers versus layers, 125
when to use, 124
N-Tier architecture, 125
ports & adapters architecture
about, 125, 127
dependency inversion principle, 126
design heuristics, 163
infrastructure integration, 127
terminology, 126
variants, 128
when to use, 128
software crisis, xxiii
space for modeling, 186
star schema, 253
strangler migration pattern, 207-210
strategic design
about, xiii, 1
business knowledge (see business knowl‐
edge)
competitive advantage
core subdomains providing, 5, 7
subdomain comparisons, 7
complexity
about, 7, 8
core subdomains, 5, 8
generic subdomains, 6, 8
software design affected, 8
subdomain comparisons, 7
design evolving, 172
domain analysis (see domain analysis)
in-house versus outsource, 10
insights from event sourcing, 111
real-world DDD, 204
modernization strategy, 205
volatility of subdomains, 9
subdomains
about, 4, 11, 228
boundaries identified
about, 11
details of business functions, 11
essentials only, 14
growth management, 180
modernization strategy, 205
subdomains as use cases, 12
bounded contexts versus, 38-41
interplay between, 39-41
business problem domains, 22
case study discussion, 284-286
(see also case study of applying DDD)
changes in design, 169-172
case study discussion, 284, 286
strategic design concerns, 172
tactical design concerns, 173-178
comparing
about, 7, 11
competitive advantage, 7
complexity, 7
in-house versus outsource, 10
volatility, 9
core subdomains, 4
(see also core subdomains)
design heuristics, 161
domain analysis examples
about, 14
BusVNext, 15
Gigmaster, 14-15
generic subdomains, 6
(see also generic subdomains)
310 
| 
Index

--- PDF page 337 / printed index page 311 ---
growth management, 180
microservices, 228
real-world DDD, 202
supporting subdomains, 6
(see also supporting subdomains)
supporting subdomains, 6, 169
boundaries, 12
change minimal, 9
competitive advantage not provided, 6, 7
complexity absent, 7, 8
design evolving
changing to core, 171
changing to generic, 171
core changing to, 172
generic changing to, 172
design heuristics, 161
example of, 6
in-house implementation, 10
real-world DDD, 203
system complexity and microservices, 221-224
system definition, 221
T
tactical design
about, xiii, 1
business logic (see business logic implemen‐
tation)
day-to-day DDD, 212
evolving design concerns, 173-178
active record to domain model, 174
domain model to event-sourced domain
model, 176
generating past transitions, 176
modeling migration events, 177
transaction script to active record, 174
real-world DDD, 204
modernization strategy, 207
testing strategies
about choosing, 164
reversed testing pyramid, 165
testing diamond, 165
testing pyramid, 165
Ticket aggregate (see help desk)
tiers versus layers in architecture, 125
time modeled via event sourcing
about, 99
event sourcing pattern, 99-108
adjusting event schema, 112
analysis, 105
event store, 107, 114
event-driven architecture versus, 234
searching earlier information values, 104
source of truth, 107, 115
version field for modification state, 104
event-sourced domain model, 108-110
advantages, 110
disadvantages, 111
forgettable payload pattern, 114
frequently asked questions
appending logs to log table, 115
audit log from text file, 114
deleting data, 114
performance, 112
scalability, 114
state-based source of truth, 115
historical perspectives
aggregate past states reconstituted, 111
generating past transitions, 176
retroactive debugging, 111
searching earlier information values, 104
version field for modification state, 104
snapshotting an aggregate’s events, 113
tomato semantic domains, 43
transaction boundary of aggregate, 87
domain services and, 93
transaction scripts, 63-69
active record manipulation, 70
changing to active records, 174
debugging, 64-68
design heuristics, 161, 163
implementation, 64
layered architecture, 124
when to use, 68
transactional versus analytical data model, 249
travelling salesman problem, 16
Tune, Nick, 160
U
Uber subdomains, 4
complexity, 5
ubiquitous language, 24-26, 37
aggregates, 92
bounded contexts integrated
about contracts, 49
cooperation, 50-52
customer–supplier, 53-55
no collaboration, 56
optimal size, 160
Index 
| 
311

--- PDF page 338 / printed index page 312 ---
case study of applying DDD
discussion, 283
domain experts, 275, 281
two separate languages, 278
challenges, 30
defining scope, 37
data mesh architecture, 263
domain complexity
about, 33
boundaries, 41
bounded contexts, 35-38
bounded contexts in real life, 42-46
inconsistent models, 33-35
subdomains versus bounded contexts, 38
EventStorming for, 196, 207
glossary for, 29
model translation, 137-142
modeling business domain, 28
domain model for business logic, 77
tools, 29
modernization strategy, 207
non-English-speaking countries, 31
published language public protocol, 55
model translation, 140
value objects, 78-81
use cases for subdomain identification, 12
V
value objects
about, 77
aggregates, 88
complexity reduction, 95
implementation, 81
ubiquitous language, 78-81
when to use, 82
Vernon, Vaughn, 277
Versioning in an Event Sourced System
(Young), 112
visualization
context map of bounded contexts, 57-58,
206
decision tree for tactical design, 166
volatility of subdomains, 9
maintainability, 10
W
Wirfs-Brock, Rebecca, 27
WolfDesk overview, xviii
Y
Young, Greg, 112, 129
312 
| 
Index