Domain driven design
Download as PPTX, PDF0 likes517 views
This document provides an overview of domain-driven design (DDD). Some key points: DDD focuses on modeling the core domain and business logic of an application rather than technical implementation details. It advocates building a domain model that represents the problem domain and expressing that model in code. Some DDD concepts discussed include entities, value objects, aggregates, repositories, domain services, bounded contexts, and context mapping. The document explains how to identify and define these concepts to structure an application around the business domain. Following DDD principles like defining a ubiquitous language, building models driven by the domain, separating bounded contexts, and mapping dependencies can help produce applications that are more maintainable, scalable, and focused on
Domain driven design
- 1. Domain Driven Design Satish Mittal VP Engineering Practo
- 2. Motivation Typical application development: Requirements from business Task breakdown Jump to implementation DB schema - tables and columns Fast, we are a Startup!
- 3. Problems 1. Your project has the same functionality implemented in the same way or different in different places? 2. You have more than one object for the same item? 3. You have objects that have properties that are not actually attributes of that object? 4. You have no or very poor relationship among related items? 5. Looking at your objects it is not possible to understand what actually the whole application is all about?
- 4. Problems Bottom-up vs Top-down approach Here-and-now vs big-picture Do I understand the domain of the application?
- 5. Solution Domain Driven Design (DDD) Coined by Eric Evans Wikipedia: Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains. Idea: Focus more on complexities intrinsic to core business domain
- 6. Domain Wikipedia: A sphere of knowledge, influence, or activity. The subject area to which the user applies a program is the domain of the software Examples: E-commerce Professional network Advertisement Healthcare ...
- 7. What is a model? It’s not just diagrams (UML, ER): views of model Model is the set of concepts that we have chosen to implement in our software Business differentiator
- 8. Pattern: Model-driven design First build an of domain model that actually represents the problem domain Then express that in code at all times Change in domain <-> Change in code
- 9. Ubiquitous Language All stakeholders should speak the same language Product-developers Developers-developers The language must be business language, and not technical details
- 10. Language: Entity A concept that has a unique identity within system Two entities can only be same if their identity is identical Typically persisted, mutable, status change Examples: Friend in Facebook Item in shopping cart: SKU News Article: URL
- 11. Language: Value Object Represents a set of attributes e.g. doors in a room, items in an order, profile details Typically it has no unique identity of its own It should be immutable In some cases, Value Object might become an entity (when unique identity is needed to invoke some action) Example: last N SearchCriteria
- 12. Language: Value Object E.g. money: int, double field in code? How about various currencies: INR/USD? Recommendation: Define unique class Money m1 = new Money("GBP", 10); Money m2 = new Money("GBP", 20); Money m3 = m1.add(m2); Typically immutable Adding m1 to m2 doesn’t alter m1; returns m3
- 13. Language: Value Object E.g. SocialSecurityNumber E.g. MobilePhoneNumber E.g. PatientRegistrationNumber Perform common validations within each class: range check, syntax, format Refactor duplicate implementations out of applications
- 14. Language: Module Package or library or namespace Collection of entities and Value Objects related to a context Focus on having as much reusable modules amongst applications across company
- 15. Language: Aggregate Roots Entity relationship types: association, aggregation or composition An aggregate root (AR) is an entity that composes other entities (as well as its own Value Object) by composition. Example: Consult Question (AR) contains multiple Answers. However any Answer can’t exist without Question Aggregated entities are referenced only by the root (may be transitively), and may not be referenced by any objects outside the aggregate. Some entities are aggregate roots themselves (single node tree)
- 16. Language: Aggregate Roots Identifying AR allows us to define the logical atomic unit of work critical section of a transaction AR is responsible for ensuring that all its child entities are always in consistent state across operations Example: Order (AR) contains OrderItems; all OrderItems must be unique Referential Integrity across ARs: Appointment for a slot must be given only if Doctor is available that day
- 17. Language: Repository Domain must be agnostic of persistence (MySQL, ES, Redis, FS..) Repository is an abstraction over persistence layer Returns collections of aggregate roots (typically meeting some criteria) Repository is a domain level concept - represented via Interface Actual implementations belong to Infrastructure layer Dependency Injection
- 18. Domain Service: Represents core business actions, operations on Domain Entities; manages business rules Example: Appointment booking, medicine order Application Service: Handles cross-cutting concerns like transactions, security etc. Infrastructure Service: Underlying tech implementation layer Example: MySQL, SMS communicator, push notification Language: Service Types
- 19. Language: Service Types Layered architecture
- 20. Spectrum of granularity Value Object < entity < aggregate < module < bounded context
- 21. Language: Bounded Context BC: The functional boundary within which domain model make sense Recommendation: Divide large application among multiple BCs More modular Separation of different concerns Helps manage and enhance application in an efficient way Each BC operates in a semi-autonomous fashion Each BC owned by separate team: domain expert Avoid BBOM (Big Ball of Mud): unstructured, duct-tape, sphagetti code
- 22. Bounded Context: Relationships published language: the interacting BCs agree on a common language (e.g. domain schema) by which they can interact with each other; open host service: a BC specifies a protocol (e.g. RPC/RESTful web service) by which any other BC can use its services; shared kernel: two BCs use a common kernel of code (e.g. a library)
- 23. Bounded Context: Relationships customer/supplier: one BC uses the services of another and is a stakeholder (customer) of that other BC. As such it can influence the services provided by that BC; conformist: one BC uses the services of another but is not a stakeholder to that other BC. As such it uses "as-is" (conforms to) the protocols or APIs provided by that BC; anti-corruption layer: one BC uses the services of another and is not a stakeholder, but aims to minimize impact from changes in the BC it depends on by introducing a set of adapters – an anti-corruption layer.
- 25. Context Map DDD recommends to draw Context Map to identify which BC do you depend upon, and which BC depend upon you Dependency graph amongst systems, with edges that capture the co-operation level Helps understand the inter-dependencies better Helps streamline upstream model changes
- 26. Thanks!