Download as ODP, PPTX
Uploaded byÜrgo Ringo
Domain Driven Design
This document provides an introduction to domain-driven design (DDD). It discusses using DDD to model an activity tracking system, including defining entities, value objects, services and other DDD patterns. The benefits of DDD include having a rich domain model and avoiding procedural code and boilerplate. In contrast, traditional object-oriented design can result in anemic domain models and more complex code over time.
More Related Content
![Jacob Marble [InfluxData] | Observability with InfluxDB IOx and OpenTelemetry...](https://cdn.slidesharecdn.com/ss_thumbnails/influxdbioxandopentelemetry-27-oct-2021jmarble-211022195239-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to Domain Driven Design
Domain Driven Design
- 1. Introduction to DomainDriven Design Aqris Software Ürgo Ringo
- 2. Sample use case– enter activity Basic flow User wants to enter new activity. System displays new form where some fields have been filled based on last entered activity. User enters activity and submits form. System validates and adds activity into persistence storage if it's valid. Business rules - activity description must not be empty - activity must start before it ends - activity duration must not overlap with existing ones - JIRA key must exist in JIRA
- 3. “Domain Model” -non-DDD way UML class diagram
- 4. Show form -non-DDD way UML sequence diagram
- 5. Submit form –non-DDD way UML sequence diagram
- 6. Benefits of non-DDDway easy to learn simple OR mapping easier to avoid performance problems Good for small systems(?)
- 7. Problems of non-DDDway procedural implementation anemic domain model boilerplate service layer fat controllers Expensive to develop/maintain
- 8. How to improvedesign Using ideas of DDD and Domain Model Domain Driven Design – E. Evans Patterns of Enterprise Application Architecture – M. Fowler
- 9. What is DDD(1) Entity e.g Activity, Project, User ValueObject e.g Duration, Address Service e.g JiraService, EmailNotificationService, TransferService
- 10. What is DDD(2) Facade e.g EnterActivityFacade, ViewActivitiesReportFacade Specification e.g ActivityDurationSpecification, UsernameSpecification Repository e.g ActivityRepository, ProjectRepository Factory e.g ActivityFactory
- 11. Domain Model -DDD way UML class diagram
- 12. Show form -DDD way UML sequence diagram
- 13. Submit form -DDD way UML sequence diagram
Editor's Notes
- #2 Introduction Knowledge of DDD?
- #7 What is small system? Need to change design if system grows
- #10 Entity – objects with a distinct identity. Core of domain model. ValueObject – objects that are primarily defined by the value of their attributes. Often immutable. Two instances whose attributes have the same values can be used interchangeably. Service – implement the workflow of the application. Fulfill a use case. Generally include behaviors that cannot be assigned to a single entity and consist of methods that act on multiple objects. Can be in domain, infrastructure or application level.
- #11 Facade – hides complexities of accessing domain model. Like application level services. Define use cases. Contain no business logic themselves. Specification – need to check that only suitable objects are used for a certain role. Keep business rules inside the domain model not leak it out into application layer. If there is large collection it can be same as Query object. Repository – manage collections of entities and define methods for finding and deleting entities. So that clients don't have to care where entities are coming from. Other == DAO but in can be special cases like query some stuff first from some service and then from db. Factory – for creating NEW complex entities. Not like Repositories.