Applying Domain-Driven Design to craft Rich Domain Models
•Télécharger en tant que PPTX, PDF•
10 j'aime•3,842 vues
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
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (10)
Similaire à Applying Domain-Driven Design to craft Rich Domain Models
Similaire à Applying Domain-Driven Design to craft Rich Domain Models (20)
Dernier
Dernier (20)
Applying Domain-Driven Design to craft Rich Domain Models
- 1. Applying Domain-Driven Design to craft Rich Domain Models Alexander van Trijffel Templates Powerpoint 6-2-2014
- 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. 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. 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’
- 7. DDD on strategic level
- 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?
- 10. DDD on tactical level
- 11. Aren’t we doing DDD already? We have entities…
- 12. And our managers/services/* know all about the logic… * enter your favorite name for the application service role here
- 13. We have a separate business layer
- 14. Hello Anemic Domain Model!
- 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. 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. 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. Anemic Domain Model example
- 20. What if we have business rules on the client Status as well? Things get messy quickly…
- 21. Empowering the domain: Encapsulating data and operations in domain objects
- 22. Encapsulating domain logic in value objects
- 23. Value object – immutable and comparable by its attributes
- 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. Money: Entity or value object?
- 26. Value objects examples Percentage Probability of Default Loss Given Default World Wide Id Global Facility Id Rating Address Country Decision Period Status
- 27. Other tactical DDD patterns to explore: • Domain Services • Domain Events • Aggregates
- 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.
- 30. Resources • Domain-Driven Design: Tackling Complexity in the Heart of Software (Eric Evans) • Implementing Domain-Driven Design Vaughn Vernon • DDD/CQRS mailing list https://groups.google.com/forum/#!forum/dddcqrs
- 31. Backup slides
- 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. 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. Empowering the domain: Encapsulated collections We provide an explicit API to manipulate the collection.
Notes de l'éditeur
- Rich Domain ModelsThe 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 Alexander will demonstrate how to put Domain-Driven Design (DDD) in 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.
- An invariant is a logical assertion that is held to always be true during a certain phase of execution
- Alistair Cockburn, 2005Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases.
- Released in 2003DDD is a methodology for designing domain models using an object oriented approach.
- Business talks about clients, ratings, regulatory reportingDevelopers talk about XSDs, inserting database records, repositories, factories.
- Do you business users talk about Assigning an WWID, Creating an WWID or adding a long id to the Client database?Capture the nouns and the verbs and have your domain model and code reflect the names used by the business to prevent translations
- An anemic model is a domain model that doesn't contain any logic. That is why the model is called anemic. It is just a container for data that can be changed and interpreted by clients. Therefore all logic is placed outside the domain models in an anemic model.An anemic model can never guarantee it's correctness at any time. An anemic model has no logic that ensures that it is in a legal state at any time.. The main problem with anemic models is that they are contradictory with fundamental object-oriented principles like: encapsulation, information hiding and bringing data and process (logic) together.Procedural programming is straight forward to write, but hard to understand if you want to understand the state handling of an application.In a behavior-rich, but anemic domain, the domain is surrounded by a multitude of services that do the actual work, and fiddle with state on our domain objects. The domain objects contain state to be persisted, but it’s not the domain objects themselves exposing any operations
- Enterprise system that is vital to the business can also be bought as an off the shelf product
- Add methods to your domain objects for changing its internal state. If The method requires any data to implement the business rules that does not relate to the domain object, give the method access to that data. The less developers you exposure the intricacies of your domain, the easier it is to ensure that the business logic will be applied correctly. For all usage scenario’s => web services, user interfaces, etcKeep the application layer thin.This layer should only be concerned with coordination: Loading an entity from the database,send a message to it, persist changes. All business logic should not be apart of the application layer.Isolate complexity. Introduce modularity.
- Currency + amount + serial number