Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • Contact Us
  • Home
  • System Architecture

Index

Written by Oleksandr Sydorenko

Updated at May 5th, 2025

Contact Us

If you still have questions or prefer to get help directly from an agent, please submit a request.
We’ll get back to you as soon as possible.

Please fill out the contact form below and we will reply as soon as possible.

  • System Architecture
+ More

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


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


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


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


growth and accidental complexity, 180, 181,

182

subdomain comparisons, 7 system complexity

definition, 94

microservices and, 221-224


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

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


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


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


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


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


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


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


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


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)


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


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


Was this article helpful?

Yes
No
Give feedback about this article

Related Articles

  • Discovering Domain Knowledge
  • Business Problems
  • Knowledge Discovery
  • Communication
  • What Is a Ubiquitous Language?

info@smartphonekey.com

  • Home
  • How It Works
  • Features
  • Residents and Tenants
  • Property Managers
  • Airbnb Hosts
  • Products
  • Blog
  • Guide for Usage and Installation
  • Our Team
  • Contact Us
  • Privacy Policy
  • Terms of Service
  • Facebook
  • Instagram
  • LinkedIn
© 2025, Smartphonekey.com Powered by Shopify
Expand