by Eric Evans
deep model An incisive expression of the primary concerns of the domain experts and their most relevant knowledge. A deep model sloughs off superficial aspects of the domain and naive interpretations.
design pattern A description of communicating objects and classes that are customized to solve a general design problem in a particular context. (Gamma et al. 1995, p. 3)
distillation A process of separating the components of a mixture to extract the essence in a form that makes it more valuable and useful. In software design, the abstraction of key aspects in a model, or the partitioning of a larger system to bring the CORE DOMAIN to the fore.
domain A sphere of knowledge, influence, or activity.
domain expert A member of a software project whose field is the domain of the application, rather than software development. Not just any user of the software, the domain expert has deep knowledge of the subject.
domain layer That portion of the design and implementation responsible for domain logic within a LAYERED ARCHITECTURE. The domain layer is where the software expression of the domain model lives.
ENTITY An object fundamentally defined not by its attributes, but by a thread of continuity and identity.
FACTORY A mechanism for encapsulating complex creation logic and abstracting the type of a created object for the sake of a client.
function An operation that computes and returns a result without observable side effects.
immutable The property of never changing observable state after creation.
implicit concept A concept that is necessary to understand the meaning of a model or design but is never mentioned.
INTENTION-REVEALING INTERFACE A design in which the names of classes, methods, and other elements convey both the original developer’s purpose in creating them and their value to a client developer.
invariant An ASSERTION about some design element that must be true at all times, except during specifically transient situations such as the middle of the execution of a method, or the middle of an uncommitted database transaction.
iteration A process in which a program is repeatedly improved in small steps. Also, one of those steps.
large-scale structure A set of high-level concepts, rules, or both that establishes a pattern of design for an entire system. A language that allows the system to be discussed and understood in broad strokes.
LAYERED ARCHITECTURE A technique for separating the concerns of a software system, isolating a domain layer, among other things.
life cycle A sequence of states an object can take on between creation and deletion, typically with constraints to ensure integrity when changing from one state to another. May include migration of an ENTITY between systems and different BOUNDED CONTEXTS.
model A system of abstractions that describes selected aspects of a domain and can be used to solve problems related to that domain.
MODEL-DRIVEN DESIGN A design in which some subset of software elements corresponds closely to elements of a model. Also, a process of codeveloping a model and an implementation that stay aligned with each other.
modeling paradigm A particular style of carving out concepts in a domain, combined with tools to create software analogs of those concepts (for example, object-oriented programming and logic programming).
REPOSITORY A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of objects.
responsibility An obligation to perform a task or know information (Wirfs-Brock et al. 2003, p. 3).
SERVICE An operation offered as an interface that stands alone in the model, with no encapsulated state.
side effect Any observable change of state resulting from an operation, whether intentional or not, even a deliberate update.
SIDE-EFFECT-FREE FUNCTION See function.
STANDALONE CLASS A class that can be understood and tested without reference to any others, except system primitives and basic libraries.
stateless The property of a design element that allows a client to use any of its operations without regard to the element’s history. A stateless element may use information that is accessible globally and may even change that global information (that is, it may have side effects) but holds no private state that affects its behavior.
strategic design Modeling and design decisions that apply to large parts of the system. Such decisions affect the entire project and have to be decided at team level.
supple design A design that puts the power inherent in a deep model into the hands of a client developer to make clear, flexible expressions that give expected results robustly. Equally important, it leverages that same deep model to make the design itself easy for the implementer to mold and reshape to accommodate new insight.
UBIQUITOUS LANGUAGE A language structured around the domain model and used by all team members to connect all the activities of the team with the software.
unification The internal consistency of a model such that each term is unambiguous and no rules contradict.
VALUE OBJECT An object that describes some characteristic or attribute but carries no concept of identity.
WHOLE VALUE An object that models a single, complete concept.
References
Alexander, C., M. Silverstein, S. Angel, S. Ishikawa, and D. Abrams. 1975. The Oregon Experiment. Oxford University Press.
Alexander, C., S. Ishikawa, and M. Silverstein. 1977. A Pattern Language: Towns, Buildings, Construction. Oxford University Press.
Alur, D., J. Crupi, and D. Malks. 2001. Core J2EE Patterns. Sun Microsystems Press.
Beck, K. 1997. Smalltalk Best Practice Patterns. Prentice Hall PTR.
Beck, K. 2000. Extreme Programming Explained: Embrace Change. Addison-Wesley.
Beck, K. 2003. Test-Driven Development: By Example. Addison-Wesley.
Buschmann, F., R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal. 1996. Pattern-Oriented Software Architecture: A System of Patterns. Wiley.
Cockburn, A. 1998. Surviving Object-Oriented Projects: A Manager’s Guide. Addison-Wesley.
Evans, E., and M. Fowler. 1997. “Specifications.” Proceedings of PLoP 97 Conference.
Fayad, M., and R. Johnson. 2000. Domain-Specific Application Frameworks. Wiley.
Fowler, M. 1997. Analysis Patterns: Reusable Object Models. Addison-Wesley.
Fowler, M. 1999. Refactoring: Improving the Design of Existing Code. Addison-Wesley.
Fowler, M. 2003. Patterns of Enterprise Application Architecture. Addison-Wesley.
Gamma, E., R. Helm, R. Johnson, and J. Vlissides. 1995. Design Patterns. Addison-Wesley.
Kerievsky, J. 2003. “Continuous Learning,” in Extreme Programming Perspectives, Michele Marchesi et al. Addison-Wesley.
Kerievsky, J. 2003. Web site: http://www.industriallogic.com/xp/refactoring.
Larman, C. 1998. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design. Prentice Hall PTR.
Merriam-Webster. 1993. Merriam-Webster’s Collegiate Dictionary. Tenth edition. Merriam-Webster.
Meyer, B. 1988. Object-oriented Software Construction. Prentice Hall PTR.
Murray-Rust, P., H. Rzepa, and C. Leach. 1995. Abstract 40. Presented as a poster at the 210th ACS Meeting in Chicago on August 21, 1995. http://www.ch.ic.ac.uk/cml/
Pinker, S. 1994. The Language Instinct: How the Mind Creates Language. HarperCollins.
Succi, G. J., D. Wells, M. Marchesi, and L. Williams. 2002. Extreme Programming Perspectives. Pearson Education.
Warmer, J., and A. Kleppe. 1999. The Object Constraint Language: Precise Modeling with UML. Addison-Wesley.
Wirfs-Brock, R., B. Wilkerson, and L. Wiener. 1990. Designing Object-Oriented Software. Prentice Hall PTR.
Wirfs-Brock, R., and A. McKean. 2003. Object Design: Roles, Responsibilities, and Collaborations. Addison-Wesley.
Photo Credits
All photographs appearing in this book have been used with permission.
Richard A. Paselk, Humboldt State Universit
y
Astrolabe (Chapter 3, page 47)
© Royalty-Free/Corbis
Fingerprint (Chapter 5, page 89), Service Station (Chapter 5, page 104), Auto Factory (Chapter 6, page 136), Librarian (Chapter 6, page 147)
Martine Jousset
Grapes (Chapter 6, page 125), Olive Trees (young and old)(Conclusion, pages 500–501)
Biophoto Associates/Photo Researchers, Inc.
Electron micrograph of Oscillatoria (Chapter 14, page 335)
Ross J. Venables
Rowers (group and single) (Chapter 14, pages 341 and 371)
Photodisc Green/Getty Images
Runners (Chapter 14, page 356), Child (Chapter 14, page 361)
U.S. National Oceanic and Atmospheric Administration
Great Wall of China (Chapter 14, page 364)
© 2003 NAMES Project Foundation, Atlanta, Georgia.
Photographer Paul Margolies. www.aidsquilt.org
AIDS Quilt (Chapter 16, page 439)
Index
A
ABSTRACT CORE, 435–437
ADAPTERS, 367
AGGREGATES
definition, 126–127
examples, 130–135, 170–171, 177–179
invariants, 128–129
local vs. global identity, 127
overview, 125–129
ownership relationships, 126
Agile design
distillation, 483
MODULES, 111
reducing dependencies, 265, 435–437, 463
supple design, 243–244, 260–264
AIDS Memorial Quilt Project, 479
Analysis models, 47–49
Analysis patterns. See also design patterns.
concept integrity, 306–307
definition, 293
example, 295–306
overview, 294
UBIQUITOUS LANGUAGE, 306–307
ANTICORRUPTION LAYER
ADAPTERS, 367
considerations, 368–369
example, 369–370
FACADES, 366–367
interface design, 366–369
overview, 364–366
relationships with external systems, 384–385
Application layer, 70, 76–79
Architectural frameworks, 70, 74, 156–157, 271–272, 495–496
ASSERTIONS, 255–259
Associations
bidirectional, 102–103
example, 169–170
for practical design, 82–88
VALUE OBJECTS, 102–103
Astrolabe, 47
Awkwardness, concept analysis, 210–216
B
Bidirectional associations, 102–103
Blind men and the elephant, 378–381
Bookmark anecdote, 57–59
BOUNDED CONTEXT. See also CONTEXT MAP.
code reuse, 344
CONTINUOUS INTEGRATION, 341–343
defining, 382
duplicate concepts, 339–340
example, 337–340
false cognates, 339–340
large-scale structure, 485–488
overview, 335–337
relationships, 352–353
splinters, 339–340
testing boundaries, 351
translation layers, 374. See also ANTICORRUPTION LAYER; PUBLISHED LANGUAGE.
vs. MODULES, 335
Brainstorming, 7–13, 207–216, 219
Breakthroughs, 193–200, 202–203
Business logic, in user interface layer, 77
Business rules, 17, 225
C
Callbacks, 73
Cargo shipping examples. See examples, cargo shipping.
Changing the design. See refactoring.
Chemical warehouse packer example, 235–241
Chemistry example, 377
Cleese, John, 5
CLOSURE OF OPERATIONS, 268–270
Code as documentation, 40
Code reuse
BOUNDED CONTEXT, 344
GENERIC SUBDOMAINS, 412–413
reusing prior art, 323–324
Cohesion, MODULES, 109–110, 113
COHESIVE MECHANISMS
and declarative style, 426–427
example, 425–427
overview, 422–425
vs. GENERIC SUBDOMAINS, 425
Common language. See PUBLISHED LANGUAGE; UBIQUITOUS LANGUAGE.
Communication, speech. See UBIQUITOUS LANGUAGE.
Communication, written. See documents; UML (Unified Modeling Language); UBIQUITOUS LANGUAGE.
Complexity, reducing. See distillation; large-scale structure; LAYERED ARCHITECTURE; supple design.
COMPOSITE pattern, 315–320
Composite SPECIFICATION, 273–282
Concept analysis. See also analysis patterns; examples, concept analysis.
awkwardness, 210–216
contradictions, 216–217
explicit constraints, 220–222
language of the domain experts, 206–207
missing concepts, 207–210
processes as domain objects, 222–223
researching existing resources, 217–219
SPECIFICATION, 223
trial and error, 219
CONCEPTUAL CONTOURS, 260–264
Conceptual layers, See LAYERED ARCHITECTURE; RESPONSIBILITY LAYERS
Configuring SPECIFICATION, 226–227
CONFORMIST, 361–363, 384–385
Constructors, 141–142, 174–175. See also FACTORIES.
CONTEXT MAP. See also BOUNDED CONTEXT.
example, 346–351
organizing and documenting, 351–352
overview, 344–346
vs. large-scale structure, 446, 485–488
CONTEXT MAP, choosing a strategy
ANTICORRUPTION LAYER, 384–385
CONFORMIST, 384–385
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS, 356–360
defining BOUNDED CONTEXT, 382
deployment, 387
external systems, 383–385
integration, 384–385
merging OPEN HOST SERVICE and PUBLISHED LANGUAGE, 394–396
merging SEPARATE WAYS and SHARED KERNEL, 389–391
merging SHARED KERNEL and CONTINUOUS INTEGRATION, 391–393
packaging, 387
phasing out legacy systems, 393–394
for a project in progress, 388–389
SEPARATE WAYS, 384–385
SHARED KERNEL, 354–355
specialized terminologies, 386–387
system under design, 385–386
team context, 382
trade-offs, 387
transformations, 389
transforming boundaries, 382–383
Context principle, 328–329. See also BOUNDED CONTEXT; CONTEXT MAP.
CONTINUOUS INTEGRATION, 341–343, 391–393. See also integration.
Continuous learning, 15–16
Contradictions, concept analysis, 216–217
CORE DOMAIN
DOMAIN VISION STATEMENT, 415–416
flagging key elements, 419–420
MECHANISMS, 425
overview, 400–405
Costs of architecture dictated MODULES, 114–115
Coupling MODULES, 109–110
Customer-focused teams, 492
CUSTOMER/SUPPLIER, 356–360
D
Database tuning, example, 102
Declarative design, 270–272
Declarative style of design, 273–282, 426–427
Decoupling from the client, 156
Deep models
distillation, 436–437
overview, 20–21
refactoring, 189–191
Deployment, 387. See also MODULES.
Design changes. See refactoring.
Design patterns. See also analysis patterns.
COMPOSITE, 315–320
FLYWEIGHT, 320
overview, 309–310
STRATEGY, 311–314
&nbs
p; vs. domain patterns, 309
Development teams. See teams.
Diagrams. See documents; UML (Unified Modeling Language).
Discovery, 191–192
Distillation. See also examples, distillation.
ABSTRACT CORE, 435–437
deep models, 436–437
DOMAIN VISION STATEMENT, 415–416
encapsulation, 422–427
HIGHLIGHTED CORE, 417–421
INTENTION-REVEALING INTERFACES, 422–427
large-scale structure, 483, 488–489
overview, 397–399
PCB design anecdote, 7–13
polymorphism, 435–437
refactoring targets, 437
role in design, 329
SEGREGATED CORE, 428–434
separating CORE concepts, 428–434
Distillation, COHESIVE MECHANISMS
and declarative style, 426–427
overview, 422–425
vs. GENERIC SUBDOMAINS, 425
Distillation, CORE DOMAIN
DOMAIN VISION STATEMENT, 415–416
flagging key elements, 419–420
MECHANISMS, 425
overview, 400–405
Distillation, GENERIC SUBDOMAINS
adapting a published design, 408
in-house solution, 409–410
off-the-shelf solutions, 407
outsourcing, 408–409
overview, 406
reusability, 412–413
risk management, 413–414
vs. COHESIVE MECHANISMS, 425
Distillation document, 418–419, 420–421
Documents
code as documentation, 40
distillation document, 418–419, 420–421
DOMAIN VISION STATEMENT, 415–416
explanatory models, 41–43
keeping current, 38–40
in project activities, 39–40
purpose of, 37–40
validity of, 38–40
UBIQUITOUS LANGUAGE, 39–40
Domain experts
gathering requirements from. See concept analysis; knowledge crunching.
language of, 206–207. See also UBIQUITOUS LANGUAGE.
Domain layer, 70, 75–79
Domain objects, life cycle, 123–124. See also AGGREGATES; FACTORIES; REPOSITORIES.
Domain patterns vs. design pattern, 309
DOMAIN VISION STATEMENT, 415–416
Domain-specific language, 272–273
Duplicate concepts, 339–340
E
Elephant and the blind men, 378–381