• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Domain Driven Design Primer

Domain Driven Design Primer



Introduction to DDD

Introduction to DDD



Total Views
Views on SlideShare
Embed Views



7 Embeds 403

http://www.igloocoder.com 357
http://feedly.com 31
http://digg.com 5
http://www.newsblur.com 4
http://www.igloocoder.com. 3
http://feeds.feedburner.com 2
http://silverreader.com 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • 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 Domain Driven Design Primer Presentation Transcript

  • 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 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
  • 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