Domain Driven Design


Published on

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

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Domain Driven Design

  1. 1. Harsh Jegadeesan’s CLASSROOM DOMAIN-DRIVEN DESIGN BITS Pilani Off-Campus Work-Integrated Learning Programmes
  2. 2. AGENDA Why Domain-Driven Design? Core Patterns
  3. 3. ERIC EVANS SPEAKS Eric Evans, the author of Domain-Driven Design, has been programming and designing systems for 25 years He asserts that for most software projects, the primary focus should be on the domain and domain logic “Domain-driven design flows from the premise that the heart of software development is knowledge of the subject matter and finding useful ways of understanding that subject matter. The complexity that we should be tackling is the complexity of the domain itself -- not the technical architecture, not the user interface, not even specific features. This means designing everything around our understanding and conception of the most essential concepts of the business and justifying any other development by how it supports that core.” From
  4. 4. “The goal of domain-driven design is to create better software by focusing on a model of the domain rather than the technology.”
  5. 5. DDD LEADS TO MODEL-DRIVEN DESIGN Domain-Driven Design leads to Model-Driven Design since developers capture their knowledge of a domain in models In particular A model-driven design is software structured around a set o domain concepts E.g.: A model-driven design for a UI framework is one in which UI concepts, such as windows and menus Teams who embrace model-driven design are aware that a change to the code IS a change to the model (and vice versa)
  6. 6. MODEL-DRIVEN DESIGN BENEFITS DDD The model and its implementation shape each other The link between model and code makes the model relevant and ensures that the work spent on analysis is not wasted The model creates a language used by all team members The language spreads domain knowledge throughout a team It allows developers to speak to domain experts (e.g. users) without translation The model is distilled knowledge Analysis is hard; we need to capture the information we get from it The model is the team’s agreed-upon way of structuring domain knowledge and distinguishing the elements of most interest
  7. 7. TACKLING COMPLEXITY The heart of software is its ability to solve domain-related problems for its users Software functionality either solves a domain-related problem or performs a domain-related task All other features support these two goals When a domain is complex, it becomes difficult to accomplish this To be successful, developers must steep themselves in the domain Problem: Most developers are not interested in this! Domain work is messy and demands a lot of knowledge not necessarily related to computer science Developers enjoy quantifiable problems that exercise their technical skills! But, domain complexity has to be tackled head-on by developers or they risk irrelevance!
  8. 8. CRUNCHING KNOWLEDGE Domain modeling requires processing (crunching) knowledge In the same way that financial analysts crunch numbers While speaking with domain experts, a domain modeler will try one organizing idea (set of concepts) after another create models, try them out, reject some, transform others Success is achieved when the modeler has created a set of abstract concepts that makes sense of all the details provided by the domain experts Domain experts are a critical part of the process Without them, developers tend to create models with concepts that seem naive and shallow to domain experts
  9. 9. INGREDIENTS OF EFFECTIVE MODELING Bind the model and the implementation As a model is developed, create rapid prototypes that test the domain These prototypes contain primarily domain concepts no UI, no persistence, no infrastructure Develop a knowledge-rich model The objects of your model should have behavior and may follow rules The model should not be just a data schema (think class diagram) but should express behavior, constraints, etc. that help solve domain related problems
  10. 10. KNOWLEDGE-RICH DESIGN Models capture more information than just the “classes” of a domain it goes beyond the “find the nouns and verbs” heuristic of some object-oriented models In particular, models capture behavior, business activities, and business rules (policies, constraints, etc.)
  11. 11. EXAMPLE: MODELING BUSINESS RULES The association might look like this:
  12. 12. EXAMPLE: OVER BOOKING CARGO? A standard practice in the shipping industry is to accept more cargo than a particular ship can carry on voyage This is know as “overbooking” and is used because there are typically always last-minute cancellations One way of specifying the overbooking policy is via a percentage of the ship’s total capacity ~ 10%
  13. 13. EXAMPLE: HIDDEN KNOWLEDGE PROBLEM Overbooking policy is not reflected in our model The policy has been recorded in a requirements document and hidden away inside one method in our application Domain-Driven Design recommends making that knowledge a part of the model: change the model, change the code (and vice versa)
  14. 14. EXAMPLE: CONTINUED, Our code would now look like this: and the OverBookingPolicy class would have a method:
  15. 15. PROBLEM It is not practical for software developers to become domain experts, or for domain experts to become software developers. Both parties can easily become confused by the plethora of undefined terminology and acronyms. Solution: Ubiquitous Language.
  17. 17. UBIQUITOUS LANGUAGE “A language structured around the domain model and used by all team members to connect all the activities of the team with the software.”
  18. 18. AGENDA Why Domain-Driven Design? Core Patterns
  19. 19. PROBLEM Domain-Driven Design is overkill. Very little domain logic. Mostly data entry / retrieval. Short deadline. Prototype or a “one off.” Low-level of modeling skill. Solution: Smart UI
  20. 20. SMART UI Put the business logic in the user interface. Create a separate user interface for every application function. Store all data in a shared relational database. Program in 4GL languages and use rapid prototyping tools; Java/C# is overkill.
  21. 21. PROBLEM Lots and lots of complicated domain logic. Long-lived project lifetime. Ambitious goals. High-level of modeling skill. Solution: (Domain) Model-Driven Design.
  22. 22. MODEL-DRIVEN DESIGN Uses a single model for both analysis (to understand the domain) and design (to implement the software). Requires an iterative development process and continuous refactoring. Developers are also modelers. This is hard.
  23. 23. ASIDE: THE MODEL DEBATE What is the relationship between the domain model and the source code? “Tightly relating the code to an underlying model gives the code meaning and makes the model relevant.”
  24. 24. PROBLEM There is too much crap in my domain logic. I wish I could pull all of this crap out so that the model is easier to see and change. Solution: Layered Architecture Crap is a scientific term.
  26. 26. USER INTERFACE LAYER Presents information to the user and interprets the user's commands.
  27. 27. APPLICATION LAYER Defines the application services: what the software actually does for the user. Orchestrates the domain objects to implement these application services. Has state reflecting the progress of a service call in execution. This layer is kept thin.
  28. 28. DOMAIN LAYER Represents concepts of the business, information about the business situation, and business rules. Maintains state reflecting the business situation. This layer is the heart of business software.
  29. 29. INFRASTRUCTURE LAYER Provides generic technical capabilities that support the higher layers. Message sending Persistence Rendering UI widgets Etc. This layer could be a library or a framework.
  30. 30. CORE OBJECTS Entities Value Objects Services
  31. 31. ENTITIES “Objects which are not defined by their attributes, but rather by a thread of continuity and identity, which remains the same throughout the life of the software and even beyond.”
  32. 32. VALUE OBJECTS “Immutable objects that have no conceptual identity and whose only purpose is to describe some attribute of another object.”
  33. 33. SERVICES “Objects that have no state and whose only purpose is to represent an operation on the domain itself.”
  34. 34. PROBLEM The domain model is too big to understand. Solution: Module.
  35. 35. MODULE “A method of organizing related concepts and tasks in order to reduce complexity.”
  37. 37. PROBLEM The object graph is biconnected. Every object has at least two references to other objects. Hard to enforce invariants. Hard to implement database transactions without touching every object in the system. Solution: Aggregate.
  38. 38. AGGREGATE “A cluster of associated objects that are treated as a unit with regard to data changes.” All external access to the cluster is through a single root Entity. The root Entity enforces invariants among the other objects.
  39. 39. PROBLEM Is the root Entity responsible for creating the Aggregate? Observation: Creation code is different than run- time behavior code. Solution: Factory.
  40. 40. FACTORY “Encapsulates the knowledge necessary for complex object creation.” Relevant patterns: Factory Method Abstract Factory Builder
  41. 41. PROBLEM How do you find an Aggregate? Navigate a network of object references. Increases coupling. Pollutes the domain objects with extra references. Pull data from the database. Should SQL go inside the domain objects? May violate data hiding principles. Solution: Repository.
  42. 42. REPOSITORY “Encapsulates database storage, retrieval, and search behavior which emulates a collection of objects.” Looks like java.util.Collection. Acts like a relational database.
  43. 43. THE END