Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Applying Domain-Driven Design to craft Rich Domain Models


Published on

The domain model is an abstraction of the problem domain that your system supports. It contains the objects and operations that are crucial to your system and its users. Therefore the design of the domain model deserves the utmost care and attention. In this session you will be introduced to Domain-Driven Design and you will learn how to put Domain-Driven Design (DDD) into practice. We will explore how to apply DDD on tactical level to design a rich domain model that encapsulates behaviour, protects its invariants and can be tested in isolation from its runtime environment

Published in: Technology, Business
  • Be the first to comment

Applying Domain-Driven Design to craft Rich Domain Models

  1. 1. Applying Domain-Driven Design to craft Rich Domain Models Alexander van Trijffel Templates Powerpoint 6-2-2014
  2. 2. Agenda • • • • • • What is a domain model? Hexagonal Architecture Ubiquitous Language When to use Domain-Driven Design? Adding behavior to the domain model Value objects
  3. 3. The domain model Represents business objects, operations and events that reflect the business processes and are meaningful to the business representatives. Business rules ‘An Asset Value Correlation multiplier must be applied for exposures with to Financial Sector Entities with assets of at least $100 bn’ ‘In case no Country of Risk is registered in UCI, the C-rating should be ‘No Rating’ Behavior ‘When an assessment is activated, a Global Facility Id is requested from UFI and assigned to the assessment’ ‘When an employee states that he has outside interests, the system accepts stock positions under certain conditions’
  4. 4. Invariants ‘A confirmed assessment has been calculated’ ‘An activated assessment has a GFID’ ‘A counterparty has an Wwid’ ‘A protection covers at least one debtor’
  5. 5. Hexagonal Architecture
  6. 6. The blue book
  7. 7. DDD on strategic level
  8. 8. Second Page : "Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum." Do we speak the same language?
  9. 9. Ubiquitous language
  10. 10. DDD on tactical level
  11. 11. Aren’t we doing DDD already? We have entities…
  12. 12. And our managers/services/* know all about the logic… * enter your favorite name for the application service role here
  13. 13. We have a separate business layer
  14. 14. Hello Anemic Domain Model!
  15. 15. When to invest in developing an ubiquitous language and implementing a Rich Domain Model? System type Domain logic Complexity Use cases DDD pays off? CRUD, Master data, Lookup Low Any No Simple, Small, Utility Low < 30 No Departmental, Narrow scoped Medium between 30 and 40 Could be Innovative Unknown ? Yes Enterprise System, Core system High > 40 Yes
  16. 16. Object Oriented Software: • Encapsulates data and operations in objects that interact with each other via the object’s interface. • Applies information hiding; Internal representation of objects is hidden to clients Object oriented means that an object manages its state and guarantees that it is in a legal state at any time.
  17. 17. By applying Object Orientation to the domain model, the model: • can ensure that its state is correct at all times • can hide complexity behind its public interface
  18. 18. Anemic Domain Model example
  19. 19. Applying business rules
  20. 20. What if we have business rules on the client Status as well? Things get messy quickly…
  21. 21. Empowering the domain: Encapsulating data and operations in domain objects
  22. 22. Encapsulating domain logic in value objects
  23. 23. Value object – immutable and comparable by its attributes
  24. 24. Model object as Entity or Value Object? Entity Value object Unique Can have many occurences Distinguished by identity Distinguished by attributes Can be changed Immutable
  25. 25. Money: Entity or value object?
  26. 26. Value objects examples Percentage Probability of Default Loss Given Default World Wide Id Global Facility Id Rating Address Country Decision Period Status
  27. 27. Other tactical DDD patterns to explore: • Domain Services • Domain Events • Aggregates
  28. 28. Summary Domain-Driven Design is a methodology that provides patterns for designing rich domains that encapsulate data and behavior. The investment in developing an ubiquitous language and implementing a rich domain model pays off for medium to large applications that implement business rules and processes. By applying Object Oriented principles to the domain, business logic is easier to test, understand and extend.
  29. 29. Thanks for your attention!
  30. 30. Resources • Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans) • Implementing Domain-Driven Design Vaughn Vernon • DDD/CQRS mailing list!forum/dddcqrs
  31. 31. Backup slides
  32. 32. Empowering the domain: Constructing objects What does it mean to be a client in our domain? • Does a client without a wwid make sense? • Does our domain even support clients without ratings? Communicate the intent of a client through the API:
  33. 33. Empowering the domain: Encapsulated collections Can the domain object guarantee that the Ratings collection is valid at all times? Does it make sense to clear all ratings? Duplicate a rating?
  34. 34. Empowering the domain: Encapsulated collections We provide an explicit API to manipulate the collection.