domain-driven design from theory to practice
DESCRIPTION
Domain-driven design from theory to practice. Artur Trosin. Presentation for: Software as Craft 2009, 14-16 May. Before start. Why DDD nowadays?. Automation of various business domains High competition for a market place Growing business complexity Complexity becomes inevitable . - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/1.jpg)
Domain-driven designfrom theory to practice
Artur Trosin
Presentation for: Software as Craft 2009, 14-16 May
![Page 2: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/2.jpg)
Before start
![Page 3: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/3.jpg)
Why DDD nowadays?
• Automation of various business domains• High competition for a market place• Growing business complexity• Complexity becomes inevitable
![Page 4: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/4.jpg)
Why DDD?
• Accidental complexity is bad• DDD is OO done right• Semantics over technology• Is discovered and NOT invented
![Page 5: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/5.jpg)
DDD benefits?
• Reduced complexity• High maintainability• Continuous collaboration and feedback• Brings to front the “Core Domain Knowledge”• Translations are reduced to minimum
![Page 6: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/6.jpg)
Domain - particular field of knowledge
![Page 7: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/7.jpg)
Complexity of most software projects is understanding the business domain and not a
technical one.
![Page 8: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/8.jpg)
Atom Model
Domain Driven Design is based on models.
![Page 9: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/9.jpg)
Even Music has a Model
![Page 10: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/10.jpg)
The key to controlling complexity is a good domain model.
Martin Fowler
![Page 11: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/11.jpg)
![Page 12: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/12.jpg)
They are two different worlds!
Business Domain(business experts)
Software Development(development team)
We need to bring them together(business domain & technical)
Successes depends on “how well you bring them together”
![Page 13: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/13.jpg)
We need common view and language!
Business DomainDomain Model
&Ubiquities Language
Software Development
![Page 14: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/14.jpg)
Domain Model - is a rigorously organized and selective abstraction of the (Business) Domain knowledge.
![Page 15: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/15.jpg)
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.
![Page 16: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/16.jpg)
Ubiquitous Language
Technical aspectsof design
Technical terms
Technical design patterns
S.O.L.I.D design principles
Domain Model Terms
DDD Patterns
Bounded Contexts
Business termsdevelopers don’t
understand
Business termseveryone uses that
don’t appear in design
Candidates to fold into model
![Page 17: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/17.jpg)
Collaboration
Business Domain
Domain Model&
Ubiquities Language
Software Development
Software
Produce
Based on
Domain Experts and Developers produce Model
Reflected in
Direct mapping between business domain concepts and software artifacts
![Page 18: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/18.jpg)
Building blocks
![Page 19: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/19.jpg)
Classic Layering
UI
Business Entities
Data Access
DB
Record Sets orData Sets or
POCO orPOJO
![Page 20: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/20.jpg)
DDD recommended-Layering
UI
Application
Domain
Infrastructure
Domain Model
Service LayerUI
Infrastructure
Serv
ice G
etaw
ays
![Page 21: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/21.jpg)
Organizing Domain Logic Patterns
Complexity of Domain Logic
Effortto enhance
Domain Model
Table ModuleTransaction Script
Source : PoEAA by Martin Fowler
![Page 22: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/22.jpg)
Mutually exclusivechoice
Model-Driven Design
Services
Entities
Value Objects
LayeredArchitecture
Smart UI
Repository
Aggregates
Factories
Express model with
Express model with
Express model with
Isolate domain with
Access with
Access with
Encapsulate with
Encapsulate withEncapsulate with
Encapsulate with
Maintain integrity with
Act as root of
X
Modules
Express model with
A model expressed in software with: Life Cycle of domain object controlled by:
![Page 23: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/23.jpg)
Associations
Country
Person
President
*
Country
Person
President
*
Country
Person
President
*
Period
![Page 24: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/24.jpg)
Entities
• An object defined primarily by its identity and not its attributes
• Could be a person, a customer, an order, etc.• Not all objects have meaningful identities…• In some systems, a class may be an ENTITY, in
others maybe not
![Page 25: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/25.jpg)
Value Objects
• Represent an aspect of the domain with NO conceptual identity
• Use when you care about what something is, not who they are
• Simple, immutable objects• NOT is same thing as a DTO [Fowler PoEAA]
![Page 26: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/26.jpg)
Services
• An operation offered as an interface that stands alone in the model
• Does not fit into any of the objects in the model• Stateless• To be used judiciously (do not turn your app into
a Transaction Script)• Use when an operation is an important domain
concept
![Page 27: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/27.jpg)
Modules
• Is larger grain of modeling and design• A method of organized related concepts• Low coupling and high cohesion• Communications mechanism.• Could be Administration, Invoicing, Reports,…
![Page 28: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/28.jpg)
Aggregates
• A cluster of associated objects that is treated as a conceptual whole
• Define consistency boundaries• A unit for the purpose of data changes• Is controlled by root
![Page 29: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/29.jpg)
Factories
• Shifts complicated object creation to FACTORY• Enforce invariants• Decouple clients and hide creation details
![Page 30: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/30.jpg)
Repositories
• Provide illusion of an in-memory collection• Provide a simple model for obtaining
persistent objects• Decouple domain model from persistence
technology• Communicate design decisions about object
access• IS NOT just DAO with CRUD
![Page 31: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/31.jpg)
Cargo Sample
![Page 32: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/32.jpg)
![Page 33: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/33.jpg)
![Page 34: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/34.jpg)
![Page 35: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/35.jpg)
Collecting Basic requirements
• Book cargo in advance• Track key handling of customer cargo
![Page 36: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/36.jpg)
Cargo •Tracking Id
Route Specification
•Origin Location•Destin Location
Leg •Load Location•Un-Load Location
Itinerary
![Page 37: Domain-driven design from theory to practice](https://reader036.vdocuments.mx/reader036/viewer/2022062520/56815fbf550346895dceba3f/html5/thumbnails/37.jpg)