This eBook includes the following formats, accessible from your Account page after purchase:
EPUB The open industry format known for its reflowable content and usability on supported mobile devices.
PDF The popular standard, used most often with the free Adobe® Reader® software.
This eBook requires no passwords or activation to read. We customize your eBook by discreetly watermarking it with your name, making it uniquely yours.
Also available in other formats.
Register your product to gain access to bonus material or receive a coupon.
Incorporate effective domain modeling into the software development process
Software design thought leader and founder of Domain Language, Eric Evans, provides a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining system design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software modeling and development.
Throughout the book, discussions are illustrated not with over-simplified, “” problems, but with realistic examples adapted from actual projects. With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.
“The book is a fun read. Eric has lots of interesting stories, and he has a way with words. I see this book as essential reading for software developers—it is a future classic.”
—Ralph Johnson, author of Design Patterns
I. PUTTING THE DOMAIN MODEL TO WORK.1. Crunching Knowledge.
Ingredients of Effective Modeling.
Deep Models.2. Communication and the Use of Language.
Modeling Out Loud.
One Team, One Language.
Documents and Diagrams.
Written Design Documents.
Explanatory Models.3. Binding Model and Implementation.
Modeling Paradigms and Tool Support.
Letting the Bones Show: Why Models Matter to Users.
II. THE BUILDING BLOCKS OF A MODEL-DRIVEN DESIGN.4. Isolating the Domain.
Relating the Layers.
The Domain Layer Is Where the Model Lives.
THE SMART UI “ANTI-PATTERN”
Other Kinds of Isolation.5. A Model Expressed in Software.
ENTITIES (A.K.A. REFERENCE OBJECTS).
Designing the Identity Operation.
Designing VALUE OBJECTS.
Designing Associations That Involve VALUE OBJECTS.
SERVICES and the Isolated Domain Layer.
Access to SERVICES.
MODULES (A.K.A. PACKAGES).
The Pitfalls of Infrastructure-Driven Packaging.
Why the Object Paradigm Predominates.
Nonobjects in an Object World.
Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms.6. The Life Cycle of a Domain Object.
Choosing FACTORIES and Their Sites.
When a Constructor Is All You Need.
Designing the Interface.
Where Does Invariant Logic Go?
ENTITY FACTORIES Versus VALUE OBJECT FACTORIES.
Reconstituting Stored Objects.
Querying a REPOSITORY.
Client Code Ignores REPOSITORY Implementation; Developers Do Not.
Implementing a REPOSITORY.
Working Within Your Frameworks.
The Relationship with FACTORIES.
Designing Objects for Relational Databases.7. Using the Language: An Extended Example.
Introducing the Cargo Shipping System.
Isolating the Domain: Introducing the Applications.
Distinguishing ENTITIES and VALUE OBJECTS.
Role and Other Attributes.
Designing Associations in the Shipping Domain.
Walking Through Scenarios.
Sample Application Feature: Changing the Destination of a Cargo.
Sample Application Feature: Repeat Business.
FACTORIES and Constructors for Cargo.
Adding a Handling Event.
Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE.
MODULES in the Shipping Model.
Introducing a New Feature: Allocation Checking.
Connecting the Two Systems.
Enhancing the Model: Segmenting the Business.
A Final Look.
III. REFACTORING TOWARD DEEPER INSIGHT.8. Breakthrough.
Story of a Breakthrough.
A Decent Model, and Yet….
A Deeper Model.
A Sobering Decision.
Focus on Basics.
Epilogue: A Cascade of New Insights.9. Making Implicit Concepts Explicit.
Digging Out Concepts.
Listen to Language.
Read the Book.
Try, Try Again.
How to Model Less Obvious Kinds of Concepts.
Processes as Domain Objects.
Applying and Implementing SPECIFICATION.10. Supple Design.
CLOSURE OF OPERATIONS.
A Declarative Style of Design.
Extending SPECIFICATIONS in a Declarative Style.
Angles of Attack.
Carve Off Subdomains.
Draw on Established Formalisms, When You Can.11. Applying Analysis Patterns.
STRATEGY (A.K.A. POLICY).
Why Not FLYWEIGHT?13. Refactoring Toward Deeper Insight.
A Design for Developers.
Crisis as Opportunity.
IV. STRATEGIC DESIGN.14. Maintaining Model Integrity.
Recognizing Splinters Within a BOUNDED CONTEXT
Testing at the CONTEXT Boundaries.
Organizing and Documenting CONTEXT MAPS.
Relationships Between BOUNDED CONTEXTS.
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS.
Designing the Interface of the ANTICORRUPTION LAYER.
Implementing the ANTICORRUPTION LAYER.
A Cautionary Tale.
OPEN HOST SERVICE.
Unifying an Elephant.
Choosing Your Model Context Strategy.
Team Decision or Higher.
Putting Ourselves in Context.
Accepting That Which We Cannot Change: Delineating the External Systems.
Relationships with the External Systems.
The System Under Design.
Catering to Special Needs with Distinct Models.
When Your Project Is Already Under Way.
Merging CONTEXTS: SEPARATE WAYS—SHARED KERNEL.
Merging CONTEXTS: SHARED KERNEL—CONTINUOUS INTEGRATION.
Phasing Out a Legacy System.
OPEN HOST SERVICE—PUBLISHED LANGUAGE.15. Distillation.
Choosing the CORE.
Who Does the Work?
An Escalation of Distillations.
Generic Doesn't Mean Reusable.
Project Risk Management.
DOMAIN VISION STATEMENT.
The Distillation Document.
The Flagged CORE.
The Distillation Document as Process Tool.
GENERIC SUBDOMAIN Versus COHESIVE MECHANISM.
When a MECHANISM Is Part of the CORE DOMAIN.
Distilling to a Declarative Style.
The Costs of Creating a SEGREGATED CORE.
Evolving Team Decision.
Deep Models Distill.
Choosing Refactoring Targets.16. Large-Scale Structure.
The “Naive Metaphor” and Why We Don't Need It.
Choosing Appropriate Layers.
PLUGGABLE COMPONENT FRAMEWORK.
How Restrictive Should a Structure Be?
Refactoring Toward a Fitting Structure.
Communication and Self-Discipline.
Restructuring Yields Supple Design.
Distillation Lightens the Load.17. Bringing the Strategy Together.
Combining Large-Scale Structures and BOUNDED CONTEXTS.
Combining Large-Scale Structures and Distillation.
Who Sets the Strategy?
Emergent Structure from Application Development.
A Customer-Focused Architecture Team.
Six Essentials for Strategic Design Decision Making.
The Same Goes for the Technical Frameworks.
Beware the Master Plan.Conclusion.