Domain Driven DesignPrimer
TheCommunicationChasm
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 BusinessNomenclatures
class GobbleGobble {…}// orclass Turkey {…}
Fluency
invoice.ChangeShipDateTo(newShipDate)
Code Impact
Aggregate Roots
PurchaserInvoiceShip ToAddress ItemsProduct DiscountCodeTaxCodeBillingAddress
Many per Application
Overlap
InvoicevsStatement.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 Ad...
class Invoice {public void ChangeShippingAddressTo(ShippingAddress newAddress) {//change address//add change fee//etc.}}
invoice.ShippingAddress.XXX =“blah”;var xyz =invoice.ShippingAddress.XXX;
Data Access
UIService LayerDomain ModelData Access
Only via Aggregate Roots
Load aggregate rootModify valuesPersist aggregate root
But now we’re loading thingswe 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-mappingfromUI -> Domain model
Public property setters
What will happenwhen you try DDD?
You’ll have to talk to thebusiness more
The business will talk to youjust like your code reads
You will struggleto give up the“One model to rule them all”
Large, complex systemswill seem simpler
Find it hard to keep themodel out of the UI
Have difficulties whenreading data for display
Erroneously try to use DDDeverywhere
donald.belcham@igloocoder.com@dbelchamwww.igloocoder.com
Upcoming SlideShare
Loading in …5
×

Domain Driven Design Primer

3,185
-1

Published on

Introduction to DDD

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,185
On Slideshare
0
From Embeds
0
Number of Embeds
18
Actions
Shares
0
Downloads
7
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Database terminology or naming creeps into the code
  • Design pattern terminology creeps into the code which is not how the business talks
  • Properties, methods, events,enums, etc should all use the terms used by the business users
  • 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.
  • Making your code read like the business speaks
  • Database terminology or naming creeps into the code
  • Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
  • Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
  • Except in the smallest of apps
  • Aggregate roots will overlap with each other. This is fine. Remember to work within the context of that aggregate root though.
  • Invoice might be detailed as outlined in our previous example. Statement.Invoice might just be a summary of that information.
  • Model clarity is significantly more valuable than code reuse in almost all cases. Interface Segregation Principle is very important here.
  • The context that you are working in is more important than the overriding concept
  • 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
  • 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.
  • Service and Data Access layers know about Domain Model, but not the other way around
  • The only items that should be passed to the data access layer are the aggregate root objects.
  • The pattern of work that results from only doing data access with the aggregate root.
  • Working with aggregate roots only can mean you are going to load data into objects in the tree that you may not use.
  • Without an ORM the aggregate root DAL approach becomes very painful
  • Leverage the functionality of the ORM. Load data only when you need it.
  • A domain model that is only properties. We want our models to be rich, or Rubenesque; properties, methods and events will exist.
  • 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.
  • 1 repository to 1 aggregate root. All data access happens via aggregate roots.
  • Domain model maps to the business functionality not to how it displays
  • 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
  • Publically exposing property setters can indicate that the model is anemic.
  • Changing your thought pattern to having overlapping aggregates and multiple classes representing the same data tables is difficult.
  • 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.
  • 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.
  • Knowing when there isn’t enough complexity to warrant DDD is just as important as knowing how to do DDD
  • Domain Driven Design Primer

    1. 1. Domain Driven DesignPrimer
    2. 2. TheCommunicationChasm
    3. 3. Reduce Verbal Friction
    4. 4. DDD and it’s components
    5. 5. Ubiquitous Language
    6. 6. Sounds Easy
    7. 7. It’s not
    8. 8. Technical Terms
    9. 9. class Customer {public string Cust_Name {…}}
    10. 10. class CustomerFactory {…}
    11. 11. Not Just Class Names
    12. 12. Industry vs BusinessNomenclatures
    13. 13. class GobbleGobble {…}// orclass Turkey {…}
    14. 14. Fluency
    15. 15. invoice.ChangeShipDateTo(newShipDate)
    16. 16. Code Impact
    17. 17. Aggregate Roots
    18. 18. PurchaserInvoiceShip ToAddress ItemsProduct DiscountCodeTaxCodeBillingAddress
    19. 19. Many per Application
    20. 20. Overlap
    21. 21. InvoicevsStatement.Invoice
    22. 22. Clarity > Reuse
    23. 23. Context is King
    24. 24. Encapsulation
    25. 25. class Invoice {public List<InvoiceItem> Items{ get; set; }}invoice.Items.Add(new InvoiceItem);
    26. 26. 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}}
    27. 27. class Invoice {public void ChangeShippingAddressTo(ShippingAddress newAddress) {//change address//add change fee//etc.}}
    28. 28. invoice.ShippingAddress.XXX =“blah”;var xyz =invoice.ShippingAddress.XXX;
    29. 29. Data Access
    30. 30. UIService LayerDomain ModelData Access
    31. 31. Only via Aggregate Roots
    32. 32. Load aggregate rootModify valuesPersist aggregate root
    33. 33. But now we’re loading thingswe might not need/use…
    34. 34. Use an ORM
    35. 35. Lazy Loading
    36. 36. DDD anti-patterns
    37. 37. Anemic Domain Model
    38. 38. Default constructors
    39. 39. 1 Repository class:1 Domain class
    40. 40. Domain model in the UI
    41. 41. Auto-mappingfromUI -> Domain model
    42. 42. Public property setters
    43. 43. What will happenwhen you try DDD?
    44. 44. You’ll have to talk to thebusiness more
    45. 45. The business will talk to youjust like your code reads
    46. 46. You will struggleto give up the“One model to rule them all”
    47. 47. Large, complex systemswill seem simpler
    48. 48. Find it hard to keep themodel out of the UI
    49. 49. Have difficulties whenreading data for display
    50. 50. Erroneously try to use DDDeverywhere
    51. 51. donald.belcham@igloocoder.com@dbelchamwww.igloocoder.com

    ×