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
Fowler naming, 71
implementation, 70
layered architecture, 124 when to use, 71
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
outbox pattern, 145
complexity reduction, 95
consistency and aggregate boundaries, 150 consistency enforcement, 84-87
domain services coordinating, 92 “Effective Aggregate Design” (Vernon), 277 entities, 84
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
decomposing data around domains, 259 domain-driven design and, 263 governance ecosystem, 262
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
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
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
subdomains, 228
modernization strategy, 205
ownership boundaries, 42
physical boundaries, 41
bounded contexts, 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
customer relationship management, 276-279
event crunchers, 279
marketing, 275
marketing hub, 282
limitations, 58
maintenance, 58
data mesh architecture, 263 design heuristics, 160
EventStorming, 194
growth management, 181 integrating
about contracts, 49
customer–supplier, 53-55 separate ways no collaboration, 56
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
(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
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
customer–supplier, 53-55 separate ways no collaboration, 56
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
analysis model, 23
(see also ubiquitous language) domain experts, xiii, 17
(see also domain experts)
EventStorming for, 207
(see also EventStorming) knowledge discovery, 22
modeling, 27
(see also modeling business domain) real-world DDD, 202
business logic implementation about, 63
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
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)
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
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
partnerships, 50
shared kernel, 50-52 customer–supplier
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
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
outbox pattern, 145
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
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 in real life, 42-46 inconsistent models, 33-35
subdomains versus bounded contexts, 38 generic subdomains, 6, 8
global complexity, 221
growth and accidental complexity, 180, 181,
subdomain comparisons, 7 system complexity
definition, 94
modernization strategy, 206
open-host service, 55 partnership changing to, 179
subdomain changes affecting, 173
D
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
partnerships, 50
customer–supplier, 53-55 separate ways no collaboration, 56
cooperation pattern of bounded contexts, 50-52 partnerships, 50
core domains versus core subdomains, 6 core subdomains, 4, 169
boundaries, 12
competitive advantage from, 5, 7
in-house implementation, 10
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
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
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
analytical data management platforms about, 254
challenges of data lake and warehouse, 258
analytical versus transactional data model about, 249
analytical models, 253
dimension table, 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
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
real-world DDD, 202 subdomain boundaries
about, 11
details of business functions, 11 essentials only, 14
subdomains as use cases, 12 subdomain types
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
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 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
building blocks aggregates, 84-92, 95
domain services, 92
entities, 83
active record to domain model, 174 domain model to event-sourced domain
model, 176
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
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
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
event-sourced domain model, 108-110 about, 99
name, 110
advantages, 110
command-query responsibility segregation pattern, 129, 134
disadvantages, 111
domain model changing to, 176 domain model versus, 99, 108 event sourcing pattern, 99-108
adjusting event schema, 112
analysis, 105
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
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
G
GDPR (General Data Protection Regulation) and data deletion, 114
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
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
accidental complexity, 180, 181, 182
aggregates, 182
bounded contexts, 181
subdomains, 180
H
help desk
domain model of implementation about, 76
entities, 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
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
about services, 217
anticorruption layer, 230 boundaries
about, 225
aggregates, 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
logical boundaries, 41
ownership boundaries, 42
physical boundaries, 41
subdomains versus, 38-41 bounded contexts integrated
about contracts, 49
customer–supplier, 53-55 duplication over collaboration, 56 separate ways no collaboration, 56
brainstorming (see EventStorming) command-query responsibility segregation,
domain expert thinking, 28 domain experts’ mental models, 22
(see also domain experts) effective modeling, 28
polyglot modeling, 129
time modeled (see event-sourced domain model)
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
snowflake schema, 253
star schema, 253
dimension table, 252
ETL processes creating OLTP coupling, 256 online transactional processing (OLTP) data,
analytical versus transactional data model, 249
ETL processes creating OLAP coupling, 256 open-host service, 55
data mesh architecture, 263 microservices, 229
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,
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
policies triggering command execution, 191 polyglot modeling, 129
data as product, 261 polyglot persistence, 129
ports & adapters architecture about, 125, 127
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,
implementation, 130
projecting, 130
synchronous projections, 130
EventStorming, 192
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
Patterns of Enterprise Application Architec‐ ture (Fowler), 71, 75, 121
S
saga pattern of aggregate communication, 147-150
about sagas, 147
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
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
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
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
terminology, 124
tiers versus layers, 125 when to use, 124
N-Tier architecture, 125 ports & adapters architecture
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
business knowledge (see business knowl‐ edge)
competitive advantage
core subdomains providing, 5, 7
subdomain comparisons, 7 complexity
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
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
generic subdomains, 6
(see also generic subdomains)
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-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
active record manipulation, 70 changing to active records, 174 debugging, 64-68
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
no collaboration, 56
optimal size, 160
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 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
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