SlideShare uma empresa Scribd logo
1 de 51
Domain Driven Design
Primer
The
Communication
Chasm
Reduce Verbal Friction
DDD and it’s components
Ubiquitous Language
Sounds Easy
It’s not
Technical Terms
class Customer {
public string Cust_Name {…}
}
class CustomerFactory {
…
}
Not Just Class Names
Industry vs Business
Nomenclatures
class GobbleGobble {
…
}
// or
class Turkey {
…
}
Fluency
invoice.ChangeShipDateTo
(newShipDate)
Code Impact
Aggregate Roots
Purchaser
Invoice
Ship To
Address Items
Product Discount
Code
Tax
Code
Billing
Address
Many per Application
Overlap
Invoice
vs
Statement.Invoice
Clarity > Reuse
Context is King
Encapsulation
class Invoice {
public List<InvoiceItem> Items
{ get; set; }
}
invoice.Items.Add
(new InvoiceItem);
class Invoice {
private List<InvoiceItem> _items;
public IEnumerable<InvoiceItem> Items
{ get {return _items;}}
public void AddItem(InvoiceItem item) {
_items.Add(item);
//change invoice total
//change invoice tax totals
//change invoice item count
}
}
class Invoice {
public void ChangeShippingAddressTo(
ShippingAddress newAddress) {
//change address
//add change fee
//etc.
}
}
invoice.ShippingAddress.XXX =
“blah”;
var xyz =
invoice.ShippingAddress.XXX;
Data Access
UI
Service Layer
Domain Model
Data Access
Only via Aggregate Roots
Load aggregate root
Modify values
Persist aggregate root
But now we’re loading things
we might not need/use…
Use an ORM
Lazy Loading
DDD anti-patterns
Anemic Domain Model
Default constructors
1 Repository class
:
1 Domain class
Domain model in the UI
Auto-mapping
from
UI -> Domain model
Public property setters
What will happen
when you try DDD?
You’ll have to talk to the
business more
The business will talk to you
just like your code reads
You will struggle
to give up the
“One model to rule them all”
Large, complex systems
will seem simpler
Find it hard to keep the
model out of the UI
Have difficulties when
reading data for display
Erroneously try to use DDD
everywhere
donald.belcham@igloocoder.com
@dbelcham
www.igloocoder.com

Mais conteúdo relacionado

Semelhante a Domain Driven Design Primer

3.2. Process Order Info (Change the name ComponentModule .docx
3.2. Process Order Info (Change the name ComponentModule .docx3.2. Process Order Info (Change the name ComponentModule .docx
3.2. Process Order Info (Change the name ComponentModule .docx
gilbertkpeters11344
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2
Hammad Rajjoub
 
Programming services-slides
Programming services-slidesProgramming services-slides
Programming services-slides
MasterCode.vn
 

Semelhante a Domain Driven Design Primer (20)

JDD 2016 - Jakub Kubrynski - Jpa - beyond copy-paste
JDD 2016 - Jakub Kubrynski - Jpa - beyond copy-pasteJDD 2016 - Jakub Kubrynski - Jpa - beyond copy-paste
JDD 2016 - Jakub Kubrynski - Jpa - beyond copy-paste
 
Rich Object Models & Angular.js
Rich Object Models & Angular.jsRich Object Models & Angular.js
Rich Object Models & Angular.js
 
Dependency injection in CakePHP
Dependency injection in CakePHPDependency injection in CakePHP
Dependency injection in CakePHP
 
JPA - Beyond copy-paste
JPA - Beyond copy-pasteJPA - Beyond copy-paste
JPA - Beyond copy-paste
 
The Science of Submissions Part IB - How to handle grouping and worksharing i...
The Science of Submissions Part IB - How to handle grouping and worksharing i...The Science of Submissions Part IB - How to handle grouping and worksharing i...
The Science of Submissions Part IB - How to handle grouping and worksharing i...
 
Design patterns for fun and profit
Design patterns for fun and profitDesign patterns for fun and profit
Design patterns for fun and profit
 
Sylius and Api Platform The story of integration
Sylius and Api Platform The story of integrationSylius and Api Platform The story of integration
Sylius and Api Platform The story of integration
 
3.2. Process Order Info (Change the name ComponentModule .docx
3.2. Process Order Info (Change the name ComponentModule .docx3.2. Process Order Info (Change the name ComponentModule .docx
3.2. Process Order Info (Change the name ComponentModule .docx
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2
 
C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2C:\Fakepath\Combating Software Entropy 2
C:\Fakepath\Combating Software Entropy 2
 
Combatendo code smells em Java
Combatendo code smells em Java Combatendo code smells em Java
Combatendo code smells em Java
 
Capstone ms2
Capstone ms2Capstone ms2
Capstone ms2
 
Fb50 posting gl document
Fb50 posting gl documentFb50 posting gl document
Fb50 posting gl document
 
Soa Symposium Expressing Service Capabilities Uniformly 2009 10 14 Bc
Soa Symposium   Expressing Service Capabilities Uniformly 2009 10 14 BcSoa Symposium   Expressing Service Capabilities Uniformly 2009 10 14 Bc
Soa Symposium Expressing Service Capabilities Uniformly 2009 10 14 Bc
 
Purchase contract
Purchase contractPurchase contract
Purchase contract
 
Greg Demo Slides
Greg Demo SlidesGreg Demo Slides
Greg Demo Slides
 
Chap10
Chap10Chap10
Chap10
 
Introduction to Domain driven design (LaravelBA #5)
Introduction to Domain driven design (LaravelBA #5)Introduction to Domain driven design (LaravelBA #5)
Introduction to Domain driven design (LaravelBA #5)
 
Programming services-slides
Programming services-slidesProgramming services-slides
Programming services-slides
 
DDD meets CQRS and event sourcing
DDD meets CQRS and event sourcingDDD meets CQRS and event sourcing
DDD meets CQRS and event sourcing
 

Mais de Donald Belcham

Design patterns you didn't know about
Design patterns you didn't know aboutDesign patterns you didn't know about
Design patterns you didn't know about
Donald Belcham
 
Programming Closer to the Iron
Programming Closer to the IronProgramming Closer to the Iron
Programming Closer to the Iron
Donald Belcham
 
Taming Brownfield Codebases with AOP
Taming Brownfield Codebases with AOPTaming Brownfield Codebases with AOP
Taming Brownfield Codebases with AOP
Donald Belcham
 
The Dark Side of Code Metrics
The Dark Side of Code MetricsThe Dark Side of Code Metrics
The Dark Side of Code Metrics
Donald Belcham
 

Mais de Donald Belcham (19)

Introduction to Messaging
Introduction to MessagingIntroduction to Messaging
Introduction to Messaging
 
Advanced messaging patterns
Advanced messaging patternsAdvanced messaging patterns
Advanced messaging patterns
 
Microservices: The Nitty Gritty
Microservices: The Nitty GrittyMicroservices: The Nitty Gritty
Microservices: The Nitty Gritty
 
Microservices: A Gentle Introduction
Microservices: A Gentle IntroductionMicroservices: A Gentle Introduction
Microservices: A Gentle Introduction
 
Intro To AOP
Intro To AOPIntro To AOP
Intro To AOP
 
Source Control Abominations
Source Control AbominationsSource Control Abominations
Source Control Abominations
 
Is There Room for Craftsmanship in Software Development
Is There Room for Craftsmanship in Software DevelopmentIs There Room for Craftsmanship in Software Development
Is There Room for Craftsmanship in Software Development
 
Reducing External Risk
Reducing External RiskReducing External Risk
Reducing External Risk
 
Performance Tuning in the Trenches
Performance Tuning in the TrenchesPerformance Tuning in the Trenches
Performance Tuning in the Trenches
 
Reliability and Resilience
Reliability and ResilienceReliability and Resilience
Reliability and Resilience
 
Reliability and Reslience
Reliability and ReslienceReliability and Reslience
Reliability and Reslience
 
Introduction To AOP
Introduction To AOPIntroduction To AOP
Introduction To AOP
 
Design patterns you didn't know about
Design patterns you didn't know aboutDesign patterns you didn't know about
Design patterns you didn't know about
 
Programming Closer to the Iron
Programming Closer to the IronProgramming Closer to the Iron
Programming Closer to the Iron
 
Taming Brownfield Codebases with AOP
Taming Brownfield Codebases with AOPTaming Brownfield Codebases with AOP
Taming Brownfield Codebases with AOP
 
Hacking Hardware
Hacking HardwareHacking Hardware
Hacking Hardware
 
Advanced AOP
Advanced AOPAdvanced AOP
Advanced AOP
 
The Dark Side of Code Metrics
The Dark Side of Code MetricsThe Dark Side of Code Metrics
The Dark Side of Code Metrics
 
Continuous Deployment
Continuous DeploymentContinuous Deployment
Continuous Deployment
 

Último

Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Safe Software
 
Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
panagenda
 

Último (20)

Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
Emergent Methods: Multi-lingual narrative tracking in the news - real-time ex...
 
Exploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone ProcessorsExploring the Future Potential of AI-Enabled Smartphone Processors
Exploring the Future Potential of AI-Enabled Smartphone Processors
 
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers:  A Deep Dive into Serverless Spatial Data and FMECloud Frontiers:  A Deep Dive into Serverless Spatial Data and FME
Cloud Frontiers: A Deep Dive into Serverless Spatial Data and FME
 
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
Apidays New York 2024 - The Good, the Bad and the Governed by David O'Neill, ...
 
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
Strategies for Unlocking Knowledge Management in Microsoft 365 in the Copilot...
 
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemkeProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
ProductAnonymous-April2024-WinProductDiscovery-MelissaKlemke
 
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, AdobeApidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
Apidays New York 2024 - Scaling API-first by Ian Reasor and Radu Cotescu, Adobe
 
Real Time Object Detection Using Open CV
Real Time Object Detection Using Open CVReal Time Object Detection Using Open CV
Real Time Object Detection Using Open CV
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost SavingRepurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
Repurposing LNG terminals for Hydrogen Ammonia: Feasibility and Cost Saving
 
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
Apidays Singapore 2024 - Building Digital Trust in a Digital Economy by Veron...
 
Why Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire businessWhy Teams call analytics are critical to your entire business
Why Teams call analytics are critical to your entire business
 
Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Polkadot JAM Slides - Token2049 - By Dr. Gavin WoodPolkadot JAM Slides - Token2049 - By Dr. Gavin Wood
Polkadot JAM Slides - Token2049 - By Dr. Gavin Wood
 
Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)Powerful Google developer tools for immediate impact! (2023-24 C)
Powerful Google developer tools for immediate impact! (2023-24 C)
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
Web Form Automation for Bonterra Impact Management (fka Social Solutions Apri...
 
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
Apidays New York 2024 - Accelerating FinTech Innovation by Vasa Krishnan, Fin...
 
Ransomware_Q4_2023. The report. [EN].pdf
Ransomware_Q4_2023. The report. [EN].pdfRansomware_Q4_2023. The report. [EN].pdf
Ransomware_Q4_2023. The report. [EN].pdf
 
GenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdfGenAI Risks & Security Meetup 01052024.pdf
GenAI Risks & Security Meetup 01052024.pdf
 
Artificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : UncertaintyArtificial Intelligence Chap.5 : Uncertainty
Artificial Intelligence Chap.5 : Uncertainty
 

Domain Driven Design Primer

Notas do Editor

  1. Database terminology or naming creeps into the code
  2. Design pattern terminology creeps into the code which is not how the business talks
  3. Properties, methods, events,enums, etc should all use the terms used by the business users
  4. Industry may seem more “proper” or “correct” but if the business uses the term so should you. One exception is when you are building an app to be used by multiple businesses in the same industry.
  5. Making your code read like the business speaks
  6. Database terminology or naming creeps into the code
  7. Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
  8. Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
  9. Except in the smallest of apps
  10. Aggregate roots will overlap with each other. This is fine. Remember to work within the context of that aggregate root though.
  11. Invoice might be detailed as outlined in our previous example. Statement.Invoice might just be a summary of that information.
  12. Model clarity is significantly more valuable than code reuse in almost all cases. Interface Segregation Principle is very important here.
  13. The context that you are working in is more important than the overriding concept
  14. When we take a business action it’s very common for many things to need to happen. Encapsulate those into methods on the Aggregate root
  15. Law of Demeter. You can pick your nose and you can pick your friends. You can’t pick your friend’s nose. You can, however, look at your friend’s nose.
  16. Service and Data Access layers know about Domain Model, but not the other way around
  17. The only items that should be passed to the data access layer are the aggregate root objects.
  18. The pattern of work that results from only doing data access with the aggregate root.
  19. Working with aggregate roots only can mean you are going to load data into objects in the tree that you may not use.
  20. Without an ORM the aggregate root DAL approach becomes very painful
  21. Leverage the functionality of the ORM. Load data only when you need it.
  22. A domain model that is only properties. We want our models to be rich, or Rubenesque; properties, methods and events will exist.
  23. If domain objects only use default constructors something is missing. Usually when you create a “new” instance of an object there will be minimum requirements for that object to be valid.
  24. 1 repository to 1 aggregate root. All data access happens via aggregate roots.
  25. Domain model maps to the business functionality not to how it displays
  26. Auto-mapping from domain to UI is a great thing. When pulling data from the UI we want to apply it to the domain model via methods exposed on the aggregate root. Auto-mapping can’t do this. It can only do property to property
  27. Publically exposing property setters can indicate that the model is anemic.
  28. Changing your thought pattern to having overlapping aggregates and multiple classes representing the same data tables is difficult.
  29. Sometimes it seems like silly extra work to keep a UI model and a domain model separate. Sometimes this can indicate that all you’re building is forms-over-data with no business richness.
  30. DDD is great for the C, U and D parts of CRUD but it isn’t a great solution for the R portion. Separating how you read data for display on the screen makes the retrieval of the data much easier. Look into CQRS which separates these two concepts nicely.
  31. Knowing when there isn’t enough complexity to warrant DDD is just as important as knowing how to do DDD