9780321125217

& bull; Specific, concrete techniques that demonstrate why domain-driven design is the heart of business software & lt;br/ & gt; & bull; Key teaching points are reinforced by entertaining stories taken from real projects & lt;br/ & gt; & bull; Contains illustrative UML diagrams and supporting Java code that help the reader apply these techniques

Eric Evans is the founder of Domain Language

Foreword

xvii

Preface

xix

Acknowledgments

xxix

Part I Putting the Domain Model to Work

1

(62)

Chapter 1: Crunching Knowledge

7

(16)

Ingredients of Effective Modeling

12

(1)

Knowledge Crunching

13

(2)

Continuous Learning

15

(2)

Knowledge-Rich Design

17

(3)

Deep Models

20

(3)

Chapter 2: Communication and the Use of Language

23

(22)

UBIQUITOUS LANGUAGE

24

(6)

Modeling Out Loud

30

(5)

One Team, One Language 32

Documents and Diagrams

35

(6)

Written Design Documents

37

(3)

Executable Bedrock

40

(1)

Explanatory Models

41

(4)

Chapter 3: Binding Model and Implementation

45

(18)

MODEL-DRIVEN DESIGN

47

(3)

Modeling Paradigms and Tool Support

50

(7)

Letting the Bones Show, Why Models Matter to Users

57

(3)

HANDS-ON MODELERS

60

(3)

Part II The Building Blocks of a Model-Driven Design

63

(124)

Chapter 4: Isolating the Domain

67

(14)

LAYERED ARCHITECTURE

68

(7)

Relating the Layers

72

(2)

Architectural Frameworks

74

(1)

The Domain Layer Is Where the Model Lives

75

(1)

THE SMART UI "ANTI-PATTERN"

76

(3)

Other Kinds of Isolation

79

(2)

Chapter 5: A Model Expressed in Software

81

(42)

Associations

82

(7)

ENTITIES (A.K.A. REFERENCE OBJECTS)

89

(8)

Modeling ENTITIES

93

(1)

Designing the Identity Operation

94

(3)

VALUE OBJECTS

97

(7)

Designing VALUE OBJECTS

99

(3)

Designing Associations That Involve VALUE OBJECTS

102

(2)

SERVICES

104

(5)

SERVICES and the Isolated Domain Layer

106

(2)

Granularity

108

(1)

Access to SERVICES

108

(1)

MODULES (A.K.A. PACKAGES)

109

(7)

Agile MODULES

111

(1)

The Pitfalls of Infrastructure-Driven Packaging

112

(4)

Modeling Paradigms

116

(7)

Why the Object Paradigm Predominates

116

(3)

Nonobjects in an Object World

119

(1)

Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms

120

(3)

Chapter 6: The Life Cycle of a Domain Object

123

(40)

AGGREGATES

125

(11)

FACTORIES

136

(11)

Choosing FACTORIES and Their Sites

139

(2)

When a Constructor Is All You Need

141

(2)

Designing the Interface

143

(1)

Where Does Invariant Logic Go?

144

(1)

ENTITY FACTORIES Versus VALUE OBJECT FACTORIES

144

(1)

Reconstituting Stored Objects

145

(2)

REPOSITORIES

147

(12)

Querying a REPOSITORY

152

(2)

Client Code Ignores REPOSITORY Implementation; Developers Do Not

154

(1)

Implementing a REPOSITORY

155

(1)

Working Within Your Frameworks

156

(1)

The Relationship with FACTORIES

157

(2)

Designing Objects for Relational Databases

159

(4)

Chapter 7: Using the Language: An Extended Example

163

(24)

Introducing the Cargo Shipping System

163

(3)

Isolating the Domain: Introducing the Applications

166

(1)

Distinguishing ENTITIES and VALUE OBJECTS

167

(2)

Role and Other Attributes

168

(1)

Designing Associations in the Shipping Domain

169

(1)

AGGREGATE Boundaries

170

(2)

Selecting REPOSITORIES

172

(1)

Walking Through Scenarios

173

(1)

Sample Application Feature: Changing the Destination of a Cargo

173

(1)

Sample Application Feature: Repeat Business

173

(1)

Object Creation

174

(3)

FACTORIES and Constructors for Cargo

174

(1)

Adding a Handling Event

175

(2)

Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE

177

(2)

MODULES in the Shipping Model

179

(2)

Introducing a New Feature: Allocation Checking

181

(5)

Connecting the Two Systems

182

(1)

Enhancing the Model: Segmenting the Business

183

(2)

Performance Tuning

185

(1)

A Final Look

186

(1)

Part III Refactoring Toward Deeper Insight

187

(140)

Chapter 8: Breakthrough

193

(12)

Story of a Breakthrough

194

(7)

A Decent Model, and Yet...

194

(2)

The Breakthrough

196

(2)

A Deeper Model

198

(1)

A Sobering Decision

199

(1)

The Payoff

200

(1)

Opportunities

201

(1)

Focus on Basics

201

(1)

Epilogue: A Cascade of New Insights

202

(3)

Chapter 9: Making Implicit Concepts Explicit

205

(38)

Digging Out Concepts

206

(13)

Listen to Language

206

(4)

Scrutinize Awkwardness

210

(6)

Contemplate Contradictions

216

(1)

Read the Book

217

(2)

Try, Try Again

219

(1)

How to Model Less Obvious Kinds of Concepts

219

(24)

Explicit Constraints

220

(2)

Processes as Domain Objects

222

(2)

SPECIFICATION

224

(3)

Applying and Implementing SPECIFICATION

227

(16)

Chapter 10: Supple Design

243

(50)

INTENTION-REVEALING INTERFACES

246

(4)

SIDE-EFFECT-FREE FUNCTIONS

250

(5)

ASSERTIONS

255

(5)

CONCEPTUAL CONTOURS

260

(5)

STANDALONE CLASSES

265

(3)

CLOSURE OF OPERATIONS

268

(2)

DECLARATIVE DESIGN

270

(3)

Domain-Specific Languages

272

(1)

A Declarative Style of Design

273

(9)

Extending SPECIFICATIONS in a Declarative Style

273

(9)

Angles of Attack

282

(27)

Carve Off Subdomains

283

(1)

Draw on Established Formalisms, When You Can

283

(10)

Chapter 11: Applying Analysis Patterns

293

(16)

Chapter 12: Relating Design Patterns to the Model

309

(12)

STRATEGY (A.K.A. POLICY)

311

(4)

COMPOSITE

315

(5)

Why Not FLYWEIGHT?

320

(1)

Chapter 13: Refactoring Toward Deeper Insight

321

(6)

Initiation

321

(1)

Exploration Teams

322

(1)

Prior Art

323

(1)

A Design for Developers

324

(1)

Timing

324

(1)

Crisis as Opportunity

325

(2)

Part IV Strategic Design

327

(172)

Chapter 14: Maintaining Model Integrity

331

(66)

BOUNDED CONTEXT

335

(6)

Recognizing Splinters Within a BOUNDED CONTEXT

339

(2)

CONTINUOUS INTEGRATION

341

(3)

CONTEXT MAP

344

(8)

Testing at the CONTEXT Boundaries

351

(1)

Organizing and Documenting CONTEXT MAPS

351

(1)

Relationships Between BOUNDED CONTEXTS

352

(2)

SHARED KERNEL

354

(2)

CUSTOMER/SUPPLIER DEVELOPMENT TEAMS

356

(5)

CONFORMIST

361

(3)

ANTICORRUPTION LAYER

364

(7)

Designing the Interface of the ANTICORRUPTION LAYER

366

(1)

Implementing the ANTICORRUPTION LAYER

366

(4)

A Cautionary Tale

370

(1)

SEPARATE WAYS

371

(3)

OPEN HOST SERVICE

374

(1)

PUBLISHED LANGUAGE

375

(3)

Unifying an Elephant

378

(3)

Choosing Your Model Context Strategy

381

(8)

Team Decision or Higher

382

(1)

Putting Ourselves in Context

382

(1)

Transforming Boundaries

382

(1)

Accepting That Which We Cannot Change: Delineating the External Systems

383

(1)

Relationships with the External Systems

384

(1)

The System Under Design

385

(1)

Catering to Special Needs with Distinct Models

386

(1)

Deployment

387

(1)

The Trade-off

388

(1)

When Your Project Is Already Under Way

388

(1)

Transformations

389

(8)

Merging CONTEXTS: SEPARATE WAYS -> SHARED KERNEL

389

(2)

Merging CONTEXTS: SHARED KERNEL -> CONTINUOUS INTEGRATION

391

(2)

Phasing Out a Legacy System

393

(1)

OPEN HOST SERVICE PUBLISHED -> LANGUAGE

394

(3)

Chapter 15: Distillation

397

(42)

CORE DOMAIN

400

(4)

Choosing the CORE

402

(1)

Who Does the Work?

403

(1)

An Escalation of Distillations

404

(2)

GENERIC SUBDOMAINS

406

(9)

Generic Doesn't Mean Reusable

412

(1)

Project Risk Management

413

(2)

DOMAIN VISION STATEMENT

415

(2)

HIGHLIGHTED CORE

417

(5)

The Distillation Document

418

(1)

The Flagged CORE

419

(1)

The Distillation Document as Process Tool

420

(2)

COHESIVE MECHANISMS

422

(4)

GENERIC SUBDOMAIN Versus COHESIVE MECHANISM

424

(1)

When a MECHANISM Is Part of the CORE DOMAIN

425

(1)

Distilling to a Declarative Style

426

(2)

SEGREGATED CORE

428

(7)

The Costs of Creating a SEGREGATED CORE

429

(1)

Evolving Team Decision

430

(5)

ABSTRACT CORE

435

(1)

Deep Models Distill

436

(1)

Choosing Refactoring Targets

437

(2)

Chapter 16: Large-Scale Structure

439

(46)

EVOLVING GIRDER

444

(3)

SYSTEM METAPHOR

447

(3)

The "Naive Metaphor" and Why We Don't Need It

448

(2)

RESPONSIBILITY LAYERS

450

(15)

Choosing Appropriate Layers

460

(5)

KNOWLEDGE LEVEL

465

(10)

PLUGGABLE COMPONENT FRAMEWORK

475

(5)

How Restrictive Should a Structure Be?

480

(1)

Refactoring Toward a Fitting Structure

481

(4)

Minimalism

481

(1)

Communication and Self Discipline

482

(1)

Restructuring Yields Supple Design

482

(1)

Distillation Lightens the Load

483

(2)

Chapter 17: Bringing the Strategy Together

485

(14)

Combining Large-Scale Structures and BOUNDED CONTEXTS

485

(3)

Combining Large-Scale Structures and Distillation

488

(2)

Assessment First

490

(1)

Who Sets the Strategy?

490

(2)

Emergent Structure from Application Development

491

(1)

A Customer-Focused Architecture Team

492

(1)

Six Essentials for Strategic Design Decision Making

492

(7)

The Same Goes for the Technical Frameworks

495

(1)

Beware the Master Plan

496

(3)

Conclusion

499

(8)

Appendix: The Use of Patterns in This Book

507

(4)

Glossary

511

(4)

References

515

(2)

Photo Credits

517

(2)

Index

519

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Leading software designers have recognized domain modeling and design as critical topics for at least twenty years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been clearly formulated, a philosophy has developed as an undercurrent in the object community, which I call "domain-driven design". I have spent the past decade focused on developing complex systems in several business and technical domains. I've tried best practices in design and development process as they have emerged from the leaders in the object-oriented development community. Some of my projects were very successful; a few failed. A feature common to the successes was a rich domain model that evolved through iterations of design and became part of the fabric of the project. This book provides a framework for making design decisions and a technical vocabulary for discussing domain design. It is a synthesis of widely accepted best practices along with my own insights and experiences. Projects facing complex domains can use this framework to approach domain-driven design systematically. Contrasting Three Projects Three projects stand out in my memory as vivid examples of the dramatic effect domain design practice has on development results. Although all three delivered useful software, only one achieved its ambitious objectives and delivered complex software that continued to evolve to meet ongoing needs of the organization. I watched one project get out of the gate fast with a useful, simple web-based trading system. Developers were flying by the seat of their pants, but simple software can be written with little attention to design. As a result of this initial success, expectations for future development were sky-high. It was at this point that I was approached to work on the second version. When I took a close look, I saw that they lacked a domain model, or even a common language on the project, and were saddled with an unstructured design. So when the project leaders did not agree with my assessment, I declined the job. A year later, they found themselves bogged down and unable to deliver a second version. Although their use of technology was not exemplary, it was the business logic that overcame them. Their first release had ossified prematurely into a high-maintenance legacy. Lifting this ceiling on complexity calls for a more serious approach to the design of domain logic. Early in my career, I was fortunate to end up on a project that did emphasize domain design. This project, in a domain at least as complex as the one above, also started with a modest initial success, delivering a simple application for institutional traders. But this delivery was followed up with successive accelerations of development. Each successive iteration opened exciting new options for integration and elaboration of functionality. The team way able to respond to the needs of the traders with flexibility and expanding capability. This upward trajectory was directly attributable to an incisive domain model, repeatedly refined and expressed in code. As the team gained new insight into the domain, the model deepened. The quality of communication improved among developers and between developers and domain experts, and the design, far from imposing an ever-heavier maintenance burden, became easier to modify and extend. Unfortunately, not all projects that start with this intention manage to arrive at this virtuous cycle. One project I joined started with lofty aspirations to build a global enterprise system based on a domain model, but finally had a disappointing result. The team had good tools, a good understanding of the business and gave serious attention to modeling. But a separation of developer roles led to a disconnect between the model and implementation, so the design did not ref

Amazon no longer offers textbook rentals. We do!

Domain-Driven Design Tackling Complexity in the Heart of Software

Domain-Driven Design Tackling Complexity in the Heart of Software

0321125215

Summary

Author Biography

Table of Contents

Supplemental Materials

Excerpts

Write a Review