SlideShare a Scribd company logo

Domain Driven Design - Distillation - Chapter 15

•
•
Mark Windholtz
Mark Windholtz

Strategic distillation is a domain-driven design technique used to refine a complex domain model. It involves separating the core domain from other domains, writing documents to describe the core domain at different levels of abstraction, and partitioning complex parts of the model. The goal is to distill the core domain concepts and their relationships to make the model easier to understand and change over time.

Related slideshows

Implementing DDD Concepts in PHP
Implementing DDD Concepts in PHPImplementing DDD Concepts in PHP
Implementing DDD Concepts in PHP
 
Android application development
Android application developmentAndroid application development
Android application development
 
Unlock the Power of Streaming Data with Kinetica and Confluent Platform
Unlock the Power of Streaming Data with Kinetica and Confluent PlatformUnlock the Power of Streaming Data with Kinetica and Confluent Platform
Unlock the Power of Streaming Data with Kinetica and Confluent Platform
 
1 of 31
Download to read offline
Domain Driven Design Distillation - Chapter 15 DDD-Meetup Cincinnati 2019-09-15 https://github.com/mwindholtz/presentations/tree/master/DDD Wikimedia Commons
Domain-driven design (DDD) An approach to software development for complex needs by connecting the implementation to an evolving model. The term was coined by Eric Evans
A Short Review or Overview …
Meeting Topic Areas 1. Strategic Patterns • Context Maps, Sub Domains, etc 2. Tactical Patterns • DomainEvents, Aggregates, etc 3. Communication Tips • Whirlpool, Knowledge Crunching, Event Storming 4. Code Examples • Build In Your Own Language: The Cargo Shipping Example
When to Apply Domain Design • For Simple systems • No worries. It fits inside a person’s head. • For Medium systems • No worries. Hire smart people so that .. • It fits inside a person’s head. Oh and write loads of Documentation! ** • For Complex systems • Starting is ok. It initially still fits inside a person’s head. • Then Documents help a while • But As It Grows … ** Documentation has an unknown expiration date. And may be wrong to begin with. Other restrictions may apply.
Typical “Agile” project progression • Feature story • Design, design, design :-) • Feature story, Feature story • Design. :-| • Feature story, Feature story, Feature story, Feature story, Feature story :-( • Feature story, Feature story, Feature story, Feature story, Feature story :-o
Code Structure: Big Ball Of Mud http://www.laputan.org/mud/ Process Diagnosis: Featureatitis
Software Craftsmanship — IS NOT ENOUGH — • Refactoring • Better names • Test Driven Design • Continuous Single Integration • Something is still missing
DDD Europe Videos 1999
“Doing” DDD • Find Bounded Contexts • Build Context Map • Focus on Core Domain • Apply Building Blocks • Engage Domain Experts to build Ubiquitous Language • Repeat … and Revisit :||
Application, as we Imagine it
Application, in Reality
Apply Strategic Distillation
Domain • A sphere of knowledge, influence, or activity. • The subject area to which the user applies a program is the domain of the software.
Why Now ? • Domain Driven Design, “Big Blue Book”, 2003 • Tactical Patterns get most of the attention • Micro-Services, 2012 • Bounded Context and Context Mapping for organization • Content of each Micro-Service • Relationships among Micro-Services
Why is DDD Difficult to Explain? • Since the Problem is Complex and Subtle • The Solution is also Complex and Subtle • Difficult to scale down into examples • Large Vocabulary of Interrelated Patterns • Pattern Languages
Building Blocks • Layered Architecture • Value Objects • Entities • Factories • Repositories • Aggregates • Services • Domain Events
Domain Driven Design - Distillation - Chapter 15
Strategic Patterns CH 15 - DISTILLATION Finding - Separating - The Core Domain Wikimedia Commons
Strategic Distillation CORE DOMAIN DOMAIN VISION STATEMENT point the way with HIGHLIGHTED CODE designate content with SEGREGATED CORE Repackaging into ABSTRACT CORE distill into GENERIC SUBDOMAIN Repackaging into distill to DECLARITIVE STYLE COHESIVE MECHANISMS unencumber from INTENTION- REVEALING INTERFACES expose capability through distill to
CORE DOMAIN • A System that is Hard to understand is hard to change • Not all parts of a system are going to be equally refined • Skilled developers are drawn to the new technical areas • The specialized core less experienced devs • Boil down the model. • Apply top talent to the CORE DOMAIN
GENERIC SUBDOMAIN • Some Parts of Model add complexity without capturing special knowledge • Don’t Clutter the CORE DOMAIN • Identify Cohesive subdomains that are not the target of the project • Examples: Email Delivery, User Management, Billing
DOMAIN VISION STATEMENT • Write a short (one page) description of the CORE DOMAIN • Leave out technical details, UI, DB, Tooling, etc •
HIGHLIGHTED CORE • Write a short 3-7 page document • Describe the main MODEL elements and their interactions
COHESIVE MECHANISMS • Some parts of the MODEL get complex • example: Algorithms • CM is part of the MODEL but a complex part that internally works together • Partition those parts in COHESIVE MECHANISMS • Provide an INTENTION-REVEALING INTERFACE
SEGREGATED CORE • ?
ABSTRACT CORE • Identify the most fundamental concepts in the model and create distinct abstract interfaces for them. • Create interactions between these abstract model elements
DECLARITIVE STYLE p.270 • Code Generator, Framework Generator • Specifications, Rules, • Metalevel, macros, templates(?) • Example:
Application, in Reality
Apply Strategic Distillation
The End Acme Internet of Things Manager Acme Smoke Detector Network

More Related Content

Domain Driven Design - Distillation - Chapter 15

  • 1. Domain Driven Design Distillation - Chapter 15 DDD-Meetup Cincinnati 2019-09-15 https://github.com/mwindholtz/presentations/tree/master/DDD Wikimedia Commons
  • 2. Domain-driven design (DDD) An approach to software development for complex needs by connecting the implementation to an evolving model. The term was coined by Eric Evans
  • 3. A Short Review or Overview …
  • 4. Meeting Topic Areas 1. Strategic Patterns • Context Maps, Sub Domains, etc 2. Tactical Patterns • DomainEvents, Aggregates, etc 3. Communication Tips • Whirlpool, Knowledge Crunching, Event Storming 4. Code Examples • Build In Your Own Language: The Cargo Shipping Example
  • 5. When to Apply Domain Design • For Simple systems • No worries. It fits inside a person’s head. • For Medium systems • No worries. Hire smart people so that .. • It fits inside a person’s head. Oh and write loads of Documentation! ** • For Complex systems • Starting is ok. It initially still fits inside a person’s head. • Then Documents help a while • But As It Grows … ** Documentation has an unknown expiration date. And may be wrong to begin with. Other restrictions may apply.
  • 6. Typical “Agile” project progression • Feature story • Design, design, design :-) • Feature story, Feature story • Design. :-| • Feature story, Feature story, Feature story, Feature story, Feature story :-( • Feature story, Feature story, Feature story, Feature story, Feature story :-o
  • 7. Code Structure: Big Ball Of Mud http://www.laputan.org/mud/ Process Diagnosis: Featureatitis
  • 8. Software Craftsmanship — IS NOT ENOUGH — • Refactoring • Better names • Test Driven Design • Continuous Single Integration • Something is still missing
  • 10. “Doing” DDD • Find Bounded Contexts • Build Context Map • Focus on Core Domain • Apply Building Blocks • Engage Domain Experts to build Ubiquitous Language • Repeat … and Revisit :||
  • 11. Application, as we Imagine it
  • 14. Domain • A sphere of knowledge, influence, or activity. • The subject area to which the user applies a program is the domain of the software.
  • 15. Why Now ? • Domain Driven Design, “Big Blue Book”, 2003 • Tactical Patterns get most of the attention • Micro-Services, 2012 • Bounded Context and Context Mapping for organization • Content of each Micro-Service • Relationships among Micro-Services
  • 16. Why is DDD Difficult to Explain? • Since the Problem is Complex and Subtle • The Solution is also Complex and Subtle • Difficult to scale down into examples • Large Vocabulary of Interrelated Patterns • Pattern Languages
  • 17. Building Blocks • Layered Architecture • Value Objects • Entities • Factories • Repositories • Aggregates • Services • Domain Events
  • 19. Strategic Patterns CH 15 - DISTILLATION Finding - Separating - The Core Domain Wikimedia Commons
  • 20. Strategic Distillation CORE DOMAIN DOMAIN VISION STATEMENT point the way with HIGHLIGHTED CODE designate content with SEGREGATED CORE Repackaging into ABSTRACT CORE distill into GENERIC SUBDOMAIN Repackaging into distill to DECLARITIVE STYLE COHESIVE MECHANISMS unencumber from INTENTION- REVEALING INTERFACES expose capability through distill to
  • 21. CORE DOMAIN • A System that is Hard to understand is hard to change • Not all parts of a system are going to be equally refined • Skilled developers are drawn to the new technical areas • The specialized core less experienced devs • Boil down the model. • Apply top talent to the CORE DOMAIN
  • 22. GENERIC SUBDOMAIN • Some Parts of Model add complexity without capturing special knowledge • Don’t Clutter the CORE DOMAIN • Identify Cohesive subdomains that are not the target of the project • Examples: Email Delivery, User Management, Billing
  • 23. DOMAIN VISION STATEMENT • Write a short (one page) description of the CORE DOMAIN • Leave out technical details, UI, DB, Tooling, etc •
  • 24. HIGHLIGHTED CORE • Write a short 3-7 page document • Describe the main MODEL elements and their interactions
  • 25. COHESIVE MECHANISMS • Some parts of the MODEL get complex • example: Algorithms • CM is part of the MODEL but a complex part that internally works together • Partition those parts in COHESIVE MECHANISMS • Provide an INTENTION-REVEALING INTERFACE
  • 27. ABSTRACT CORE • Identify the most fundamental concepts in the model and create distinct abstract interfaces for them. • Create interactions between these abstract model elements
  • 28. DECLARITIVE STYLE p.270 • Code Generator, Framework Generator • Specifications, Rules, • Metalevel, macros, templates(?) • Example:
  • 31. The End Acme Internet of Things Manager Acme Smoke Detector Network