| |
| |
| Foreword | |
| |
| |
| Preface | |
| |
| |
| Acknowledgments | |
| |
| |
| |
| Putting the Domain Model to Work | |
| |
| |
| |
| Crunching Knowledge | |
| |
| |
| Ingredients of Effective Modeling | |
| |
| |
| Knowledge Crunching | |
| |
| |
| Continuous Learning | |
| |
| |
| Knowledge-Rich Design | |
| |
| |
| Deep Models | |
| |
| |
| |
| Communication and the Use of Language | |
| |
| |
| Ubiquitous Language | |
| |
| |
| Modeling Out Loud | |
| |
| |
| One Team, One Language | |
| |
| |
| Documents and Diagrams | |
| |
| |
| Written Design Documents | |
| |
| |
| Executable Bedrock | |
| |
| |
| Explanatory Models | |
| |
| |
| |
| Binding Model and Implementation | |
| |
| |
| Model-Driven Design | |
| |
| |
| Modeling Paradigms and Tool Support | |
| |
| |
| Letting the Bones Show: Why Models Matter to Users | |
| |
| |
| Hands-On Modelers | |
| |
| |
| |
| The Building Blocks of a Model-Driven Design | |
| |
| |
| |
| Isolating the Domain | |
| |
| |
| Layered Architecture | |
| |
| |
| Relating the Layers | |
| |
| |
| Architectural Frameworks | |
| |
| |
| The Domain Layer Is Where the Model Lives | |
| |
| |
| The Smart UI "Anti-Pattern" | |
| |
| |
| Other Kinds of Isolation | |
| |
| |
| |
| A Model Expressed in Software | |
| |
| |
| Associations | |
| |
| |
| Entities (a.k.a. Reference Objects) | |
| |
| |
| Modeling Entities | |
| |
| |
| Designing the Identity Operation | |
| |
| |
| Value Objects | |
| |
| |
| Designing Value Objects | |
| |
| |
| Designing Associations That Involve Value Objects | |
| |
| |
| Services | |
| |
| |
| Services and the Isolated Domain Layer | |
| |
| |
| Granularity | |
| |
| |
| Access to Services | |
| |
| |
| Modules (a.k.a. Packages) | |
| |
| |
| Agile Modules | |
| |
| |
| The Pitfalls of Infrastructure-Driven Packaging | |
| |
| |
| Modeling Paradigms | |
| |
| |
| Why the Object Paradigm Predominates | |
| |
| |
| Nonobjects in an Object World | |
| |
| |
| Sticking with Model-Driven Design When Mixing Paradigms | |
| |
| |
| |
| The Life Cycle of a Domain Object | |
| |
| |
| Aggregates | |
| |
| |
| Factories | |
| |
| |
| 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 | |
| |
| |
| Repositories | |
| |
| |
| 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 | |
| |
| |
| |
| 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 | |
| |
| |
| Aggregate Boundaries | |
| |
| |
| Selecting Repositories | |
| |
| |
| Walking Through Scenarios | |
| |
| |
| Sample Application Feature: Changing the Destination of a Cargo | |
| |
| |
| Sample Application Feature: Repeat Business | |
| |
| |
| Object Creation | |
| |
| |
| 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 | |
| |
| |
| Performance Tuning | |
| |
| |
| A Final Look | |
| |
| |
| |
| Refactoring Toward Deeper Insight | |
| |
| |
| |
| Breakthrough | |
| |
| |
| Story of a Breakthrough | |
| |
| |
| A Decent Model, and Yet ... | |
| |
| |
| The Breakthrough | |
| |
| |
| A Deeper Model | |
| |
| |
| A Sobering Decision | |
| |
| |
| The Payoff | |
| |
| |
| Opportunities | |
| |
| |
| Focus on Basics | |
| |
| |
| Epilogue: A Cascade of New Insights | |
| |
| |
| |
| Making Implicit Concepts Explicit | |
| |
| |
| Digging Out Concepts | |
| |
| |
| Listen to Language | |
| |
| |
| Scrutinize Awkwardness | |
| |
| |
| Contemplate Contradictions | |
| |
| |
| Read the Book | |
| |
| |
| Try, Try Again | |
| |
| |
| How to Model Less Obvious Kinds of Concepts | |
| |
| |
| Explicit Constraints | |
| |
| |
| Processes as Domain Objects | |
| |
| |
| Specification | |
| |
| |
| Applying and Implementing Specification | |
| |
| |
| |
| Supple Design | |
| |
| |
| Intention-Revealing Interfaces | |
| |
| |
| Side-Effect-Free Functions | |
| |
| |
| Assertions | |
| |
| |
| Conceptual Contours | |
| |
| |
| Standalone Classes | |
| |
| |
| Closure of Operations | |
| |
| |
| Declarative Design | |
| |
| |
| Domain-Specific Languages | |
| |
| |
| A Declarative Style of Design | |
| |
| |
| Extending Specifications in a Declarative Style | |
| |
| |
| Angles of Attack | |
| |
| |
| Carve Off Subdomains | |
| |
| |
| Draw on Established Formalisms, When You Can | |
| |
| |
| |
| Applying Analysis Patterns | |
| |
| |
| |
| Relating Design Patterns to the Model | |
| |
| |
| Strategy (A.K.A. Policy) | |
| |
| |
| Composite | |
| |
| |
| Why Not Flyweight? | |
| |
| |
| |
| Refactoring Toward Deeper Insight | |
| |
| |
| Initiation | |
| |
| |
| Exploration Teams | |
| |
| |
| Prior Art | |
| |
| |
| A Design for Developers | |
| |
| |
| Timing | |
| |
| |
| Crisis as Opportunity | |
| |
| |
| |
| Strategic Design | |
| |
| |
| |
| Maintaining Model Integrity | |
| |
| |
| Bounded Context | |
| |
| |
| Recognizing Splinters Within a Bounded Context | |
| |
| |
| Continuous Integration | |
| |
| |
| Context Map | |
| |
| |
| Testing at the Context Boundaries | |
| |
| |
| Organizing and Documenting Context Maps | |
| |
| |
| Relationships Between Bounded Contexts | |
| |
| |
| Shared Kernel | |
| |
| |
| Customer/Supplier Development Teams | |
| |
| |
| Conformist | |
| |
| |
| Anticorruption Layer | |
| |
| |
| Designing the Interface of the Anticorruption Layer | |
| |
| |
| Implementing the Anticorruption Layer | |
| |
| |
| A Cautionary Tale | |
| |
| |
| Separate Ways | |
| |
| |
| Open Host Service | |
| |
| |
| Published Language | |
| |
| |
| Unifying an Elephant | |
| |
| |
| Choosing Your Model Context Strategy | |
| |
| |
| Team Decision or Higher | |
| |
| |
| Putting Ourselves in Context | |
| |
| |
| Transforming Boundaries | |
| |
| |
| 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 | |
| |
| |
| Deployment | |
| |
| |
| The Trade-off | |
| |
| |
| When Your Project Is Already Under Way | |
| |
| |
| Transformations | |
| |
| |
| Merging Contexts: Separate Ways to Shared Kernel | |
| |
| |
| Merging Contexts: Shared Kernel to Continuous Integration | |
| |
| |
| Phasing Out a Legacy System | |
| |
| |
| Open Host Service to Published Language | |
| |
| |
| |
| Distillation | |
| |
| |
| Core Domain | |
| |
| |
| Choosing the Core | |
| |
| |
| Who Does the Work? | |
| |
| |
| An Escalation of Distillations | |
| |
| |
| Generic Subdomains | |
| |
| |
| Generic Doesn't Mean Reusable | |
| |
| |
| Project Risk Management | |
| |
| |
| Domain Vision Statement | |
| |
| |
| Highlighted Core | |
| |
| |
| The Distillation Document | |
| |
| |
| The Flagged Core | |
| |
| |
| The Distillation Document as Process Tool | |
| |
| |
| Cohesive Mechanisms | |
| |
| |
| Generic Subdomain Versus Cohesive Mechanism | |
| |
| |
| When a Mechanism Is Part of the Core Domain | |
| |
| |
| Distilling to a Declarative Style | |
| |
| |
| Segregated Core | |
| |
| |
| The Costs of Creating a Segregated Core | |
| |
| |
| Evolving Team Decision | |
| |
| |
| Abstract Core | |
| |
| |
| Deep Models Distill | |
| |
| |
| Choosing Refactoring Targets | |
| |
| |
| |
| Large-Scale Structure | |
| |
| |
| Evolving Order | |
| |
| |
| System Metaphor | |
| |
| |
| The "Naive Metaphor" and Why We Don't Need It | |
| |
| |
| Responsibility Layers | |
| |
| |
| Choosing Appropriate Layers | |
| |
| |
| Knowledge Level | |
| |
| |
| Pluggable Component Framework | |
| |
| |
| How Restrictive Should a Structure Be? | |
| |
| |
| Refactoring Toward a Fitting Structure | |
| |
| |
| Minimalism | |
| |
| |
| Communication and Self-Discipline | |
| |
| |
| Restructuring Yields Supple Design | |
| |
| |
| Distillation Lightens the Load | |
| |
| |
| |
| Bringing the Strategy Together | |
| |
| |
| Combining Large-Scale Structures and Bounded Contexts | |
| |
| |
| Combining Large-Scale Structures and Distillation | |
| |
| |
| Assessment First | |
| |
| |
| 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 | |
| |
| |
| |
| The Use of Patterns in This Book | |
| |
| |
| Glossary | |
| |
| |
| References | |
| |
| |
| Photo Credits | |
| |
| |
| Index | |