Download - Domain Driven Design
![Page 1: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/1.jpg)
DOMAIN-DRIVEN DESIGN
Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM
BITS PilaniOff-Campus Work-Integrated Learning Programmes
![Page 2: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/2.jpg)
![Page 3: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/3.jpg)
AGENDA
� Why Domain-Driven Design?
� Core Patterns
![Page 4: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/4.jpg)
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 logiclogic
� “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 http://domaindrivendesign.org/articles/blog/evans_eric_ddd_and_mdd.html
![Page 5: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/5.jpg)
“The goal of domain-driven design is to create
better software by focusing on a model of the
domain rather than the technology.”domain rather than the technology.”
![Page 6: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/6.jpg)
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 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)
![Page 7: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/7.jpg)
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 membersmembers
� 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
![Page 8: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/8.jpg)
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 � 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!
![Page 9: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/9.jpg)
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
![Page 10: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/10.jpg)
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
![Page 11: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/11.jpg)
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.)
![Page 12: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/12.jpg)
EXAMPLE: MODELING BUSINESS RULES
The association might look like this:� The association might look like this:
![Page 13: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/13.jpg)
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 cancellationsthere are typically always last-minute cancellations
� One way of specifying the overbooking policy is via a
percentage of the ship’s total capacity ~ 10%
![Page 14: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/14.jpg)
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 � Domain-Driven Design recommends making that
knowledge a part of the model: change the model,
change the code (and vice versa)
![Page 15: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/15.jpg)
EXAMPLE: CONTINUED,
� Our code would now look like this:
� and the OverBookingPolicy class would have a method:
![Page 16: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/16.jpg)
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 � Both parties can easily become confused by the
plethora of undefined terminology and acronyms.
� Solution: Ubiquitous Language.
![Page 17: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/17.jpg)
UBIQUITOUS LANGUAGE
![Page 18: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/18.jpg)
UBIQUITOUS LANGUAGE
“A language structured around the
domain model and used by all team
members to connect all the activitiesmembers to connect all the activities
of the team with the software.”
![Page 19: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/19.jpg)
![Page 20: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/20.jpg)
AGENDA
� Why Domain-Driven Design?
� Core Patterns
![Page 21: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/21.jpg)
PROBLEM
� Domain-Driven Design is overkill.
� Very little domain logic.
� Mostly data entry / retrieval.
� Short deadline.
� Prototype or a “one off.”� Prototype or a “one off.”
� Low-level of modeling skill.
� Solution: Smart UI
![Page 22: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/22.jpg)
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.� Store all data in a shared relational database.
� Program in 4GL languages and use rapid prototyping tools; Java/C# is overkill.
![Page 23: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/23.jpg)
PROBLEM
� Lots and lots of complicated domain logic.
� Long-lived project lifetime.
� Ambitious goals.
High-level of modeling skill.� High-level of modeling skill.
� Solution: (Domain) Model-Driven Design.
![Page 24: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/24.jpg)
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.continuous refactoring.
� Developers are also modelers.
This is hard.
![Page 25: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/25.jpg)
ASIDE: THE MODEL DEBATE
What is the relationship between the
domain model and the source code?
“Tightly relating the code to an underlying model “Tightly relating the code to an underlying model
gives the code meaning and
makes the model relevant.”
![Page 26: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/26.jpg)
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� Solution: Layered Architecture
Crap is a scientific term.
![Page 27: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/27.jpg)
LAYERED ARCHITECTURE
![Page 28: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/28.jpg)
USER INTERFACE LAYER
� Presents information to the user and interprets
the user's commands.
![Page 29: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/29.jpg)
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 � Has state reflecting the progress of a service call in execution.
� This layer is kept thin.
![Page 30: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/30.jpg)
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.� This layer is the heart of business software.
![Page 31: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/31.jpg)
INFRASTRUCTURE LAYER
� Provides generic technical capabilities that
support the higher layers.
� Message sending
� Persistence� Persistence
� Rendering UI widgets
� Etc.
� This layer could be a library or a framework.
![Page 32: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/32.jpg)
CORE OBJECTS
� Entities
� Value Objects
� Services
![Page 33: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/33.jpg)
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 thethe same throughout the life of the
software and even beyond.”
![Page 34: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/34.jpg)
VALUE OBJECTS
“Immutable objects that have no
conceptual identity and whose only
purpose is to describe some attributepurpose is to describe some attribute
of another object.”
![Page 35: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/35.jpg)
SERVICES
“Objects that have no state and whose
only purpose is to represent an operation
on the domain itself.”on the domain itself.”
![Page 36: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/36.jpg)
PROBLEM
� The domain model is too big to understand.
� Solution: Module.
![Page 37: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/37.jpg)
MODULE
“A method of organizing related concepts
and tasks in order to reduce complexity.”
![Page 38: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/38.jpg)
DOMAIN OBJECT LIFE CYCLE
![Page 39: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/39.jpg)
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 � Hard to implement database transactions
without touching every object in the system.
� Solution: Aggregate.
![Page 40: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/40.jpg)
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.is through a single root Entity.
The root Entity enforces invariants
among the other objects.
![Page 41: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/41.jpg)
PROBLEM
� Is the root Entity responsible for creating the
Aggregate?
� Observation: Creation code is different than run-
time behavior code.time behavior code.
� Solution: Factory.
![Page 42: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/42.jpg)
FACTORY
“Encapsulates the knowledge necessary
for complex object creation.”
Relevant patterns:� Relevant patterns:
� Factory Method
� Abstract Factory
� Builder
![Page 43: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/43.jpg)
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.Pull data from the database.
� Should SQL go inside the domain objects?
� May violate data hiding principles.
� Solution: Repository.
![Page 44: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/44.jpg)
REPOSITORY
“Encapsulates database storage,
retrieval, and search behavior which
emulates a collection of objects.”
� Looks like java.util.Collection.
� Acts like a relational database.
![Page 45: Domain Driven Design](https://reader034.vdocument.in/reader034/viewer/2022052301/554f352eb4c905471e8b4570/html5/thumbnails/45.jpg)
THE END