More Related Content
Similar to Domain Driven Design Primer
Domain Driven Design Primer
- 1.
- 2.
- 3.
- 4. DDD and it’scomponents
- 5.
- 6.
- 7.
- 8.
- 9. class Customer { publicstring Cust_Name {…} }
- 10.
- 11. Not Just ClassNames
- 12.
- 13. class GobbleGobble { … } //or class Turkey { … }
- 14.
- 15.
- 16.
- 17.
- 18. Purchaser Invoice Ship To Address Items ProductDiscount Code Tax Code Billing Address
- 19.
- 20.
- 21.
- 22.
- 23.
- 24.
- 25. class Invoice { publicList<InvoiceItem> Items { get; set; } } invoice.Items.Add (new InvoiceItem);
- 26. class Invoice { privateList<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. class Invoice { publicvoid ChangeShippingAddressTo( ShippingAddress newAddress) { //change address //add change fee //etc. } }
- 28. invoice.ShippingAddress.XXX = “blah”; var xyz= invoice.ShippingAddress.XXX;
- 29.
- 30.
- 31. Only via AggregateRoots
- 32. Load aggregate root Modifyvalues Persist aggregate root
- 33. But now we’reloading things we might not need/use…
- 34.
- 35.
- 36.
- 37.
- 38.
- 39. 1 Repository class : 1Domain class
- 40. Domain model inthe UI
- 41.
- 42.
- 43. What will happen whenyou try DDD?
- 44. You’ll have totalk to the business more
- 45. The business willtalk to you just like your code reads
- 46. You will struggle togive up the “One model to rule them all”
- 47. Large, complex systems willseem simpler
- 48. Find it hardto keep the model out of the UI
- 49. Have difficulties when readingdata for display
- 50. Erroneously try touse DDD everywhere
- 51.
Editor's Notes
- #10 Database terminology or naming creeps into the code
- #11 Design pattern terminology creeps into the code which is not how the business talks
- #12 Properties, methods, events,enums, etc should all use the terms used by the business users
- #13 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.
- #15 Making your code read like the business speaks
- #16 Database terminology or naming creeps into the code
- #18 Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
- #19 Business usually talks in focused areas. i.e. Inventory or Invoicing or Accounting.
- #20 Except in the smallest of apps
- #21 Aggregate roots will overlap with each other. This is fine. Remember to work within the context of that aggregate root though.
- #22 Invoice might be detailed as outlined in our previous example. Statement.Invoice might just be a summary of that information.
- #23 Model clarity is significantly more valuable than code reuse in almost all cases. Interface Segregation Principle is very important here.
- #24 The context that you are working in is more important than the overriding concept
- #28 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
- #29 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.
- #31 Service and Data Access layers know about Domain Model, but not the other way around
- #32 The only items that should be passed to the data access layer are the aggregate root objects.
- #33 The pattern of work that results from only doing data access with the aggregate root.
- #34 Working with aggregate roots only can mean you are going to load data into objects in the tree that you may not use.
- #35 Without an ORM the aggregate root DAL approach becomes very painful
- #36 Leverage the functionality of the ORM. Load data only when you need it.
- #38 A domain model that is only properties. We want our models to be rich, or Rubenesque; properties, methods and events will exist.
- #39 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.
- #40 1 repository to 1 aggregate root. All data access happens via aggregate roots.
- #41 Domain model maps to the business functionality not to how it displays
- #42 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
- #43 Publically exposing property setters can indicate that the model is anemic.
- #47 Changing your thought pattern to having overlapping aggregates and multiple classes representing the same data tables is difficult.
- #49 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.
- #50 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.
- #51 Knowing when there isn’t enough complexity to warrant DDD is just as important as knowing how to do DDD