Domain-Driven Design
Page 50
SHARED KERNEL
example, 359
merging with CONTINUOUS INTEGRATION, 391–393
merging with SEPARATE WAYS, 389–391
overview, 354–355
Sharing VALUE OBJECTS, 100–101
Shipping examples. See examples, cargo shipping.
Side effects, 250. See also ASSERTIONS.
SIDE-EFFECT-FREE FUNCTIONS, 250–254, 285–286
Simplifying your design. See distillation; large-scale structure; LAYERED ARCHITECTURE.
SMART UI, 73
SPECIFICATION. See also analysis patterns; design patterns.
applying, 227
business rules, 225
combining. See composite SPECIFICATION.
composite, 273–281
configuring, 226–227
definition, 225–226
example, 29, 235–241, 279–282
generating objects, 234–235
implementing, 227
overview, 224–227
purpose, 227
selecting objects, 229–234
validating objects, 227, 228–229
Speech, common language. See UBIQUITOUS LANGUAGE.
Speech, modeling through, 30–32
STANDALONE CLASSES, 265–267
Strategic design. See also large-scale structure.
assessing the situation, 490
customer-focused architecture teams, 492
developers, role of, 494
essential requirements, 492–495
evolution, 493
EVOLVING ORDER, 491
feedback process, 493
minimalism, 494–495
multiple development teams, 491
objects, role of, 494
setting a strategy, 490–492
team communication, 492
team makeup, 494
technical frameworks, 495–497
STRATEGY pattern, 19, 311–314
Supple design
approaches to, 282–292
ASSERTIONS, 255–259
CLOSURE OF OPERATIONS, 268–270
composite SPECIFICATION, 273–282
CONCEPTUAL CONTOURS, 260–264
declarative design, 270–272
declarative style of design, 273–282
domain-specific language, 272–273
example, 247–249
INTENTION-REVEALING INTERFACES, 246–249
interdependencies, 265–267
large-scale structure, 480–483
naming conventions, 247
overview, 243–245
SIDE-EFFECT-FREE FUNCTIONS, 250–254, 285–286
STANDALONE CLASSES, 265–267
SYSTEM METAPHOR, 447–449
System under design, 385–386
T
Team context, 382
Teams
choosing a strategy, 382
communication, large-scale structure, 482
customer-focused, 492
defining BOUNDED CONTEXT, 382
developer community, maturity of, 117–119
exploration, 322–323
Teams, and strategic design
communication, 492
customer-focused, 492
developers, role of, 494
makeup of, 494
multiple teams, 491
Teams, multiple
ANTICORRUPTION LAYER, 364–370
CONFORMIST, 361–363
CUSTOMER/SUPPLIER, 356–360
example, 358–360
SHARED KERNEL, 354–355, 359
strategic design, 491
Terminology. See BOUNDED CONTEXT; PUBLISHED LANGUAGE; UBIQUITOUS LANGUAGE.
Testing boundaries, 351
Transaction control, 156
TRANSACTION SCRIPT, 79
Transformations, 389
Transforming boundaries, 382–383
Transient objects, 149
Translation layers, 374
Tuning a database, example, 102
U
UBIQUITOUS LANGUAGE. See also PUBLISHED LANGUAGE.
analysis patterns, 306–307
cargo router example, 27–30
consistent use of, 32–35
designing objects for relational databases, 160–161
domain-specific language, 272–273
language of the domain experts, 206–207
overview, 24–27
refining the model, 30–32
specialized terminologies, 386–387
requirements analysis, 25
speech, role of, 30–32
UML (Unified Modeling Language), 35–37
Unification, 332. See also CONTINUOUS INTEGRATION.
Unified Modeling Language (UML), 35–37
Updating the design. See refactoring.
User interface layer
business logic, 77
definition, 70
separating from application and domain, 76–79
V
Validating objects, 227, 228–229
VALUE OBJECTS. See also ENTITIES; SERVICES.
associations, 102–103
bidirectional associations, 102–103
change management, 101
clustering. See AGGREGATES.
designing, 99–102
example, 167–168
immutability, 100–101
object assemblages, 98–99
overview, 97–99
passing as parameters, 99
referencing ENTITIES, 98–99
sharing, 100–101
tuning a database, example, 102
Vision statement. See DOMAIN VISION STATEMENT.
Vocabulary. See PUBLISHED LANGUAGE; UBIQUITOUS LANGUAGE.
W
Waterfall design method, 14
Web site bookmark anecdote, 57–59
Footnotes
Chapter 1
1. Brian Marick mentioned this example to me.
Chapter 5
1. A model ENTITY is not the same thing as a Java “entity bean.” Entity beans were meant as a framework for implementing ENTITIES, more or less, but it hasn’t worked out that way. Most ENTITIES are implemented as ordinary objects. Regardless of how they are implemented, ENTITIES are a fundamental distinction in a domain model.
2. The WHOLE VALUE pattern, by Ward Cunningham.
Chapter 6
1. David Siegel devised and used this system on projects in the 1990s but has not published it.
Part III
1. Patterns as targets for refactoring were briefly mentioned in Gamma et al. (1995). Joshua Kerievsky has developed refactoring to patterns into a more mature and useful form (Kerievsky 2003).
Chapter 10
1. The WHOLE VALUE pattern, by Ward Cunningham.
Chapter 14
1. Reagan translated an old Russian saying that summed up the heart of the matter for both sides—another metaphor for bridging contexts.
Chapter 16
1. SYSTEM METAPHOR finally made sense to me when I heard Ward Cunningham use this firewall example in a workshop lecture.
2. POSA is short for Pattern-Oriented Software Architecture, by Buschmann et al. 1996.