Domain Driven Design

• Domain
Domain Driven Design
• Term first described by Erik Evans to describe software architecture and design technique
• Main objective to reduce the complexity required to develop a solution for the domain we are
targeting
• We Need to work with a Domain expert to build a domain language that is more understandable
by both the developer and the expert
• In all we can some it up as DDD’s goal is to build system that are more maintainable,
understandable and help us achieve required business functionality by modelling the system on
domain.
• It Isn’t about writing code that works but it should be understandable and maintainable in future
Where to use DDD
• When the system would be used for Long term
• Have a high domain complexity
• There is benefit in communication using common domain
language
Building Blocks
• Domain: The subject area around which our program us going to be
built
• Domain Model: A system of abstractions that describes selected
aspects of a domain and can be used to solve problems related to
that domain..
• Bounded Context: It defines the limit or boundary till which a model
in applicable
• Ubiquitous language: The common domain language structured
around the domain model used within the team and the code itself.
Ubiquitous Language
• Using the model discussed as the backbone language
• Use it consistently in diagrams , documentation and speech .
• Iron out and resolve confusion over terms and expressions via
conversation
Terms in DDD
• Entity: An entity is an object with an identity. Something that is not
only defined by its attributes but also by its functionality within a
system.
• Value: A value object is container of attributes, a bag of attributes.
• Domain Event: A domain event is an object that represents an event,
something that happens in services.
• Aggregate: Aggregates are a collection of objects bounded together by
a root entity,
• Root entity gives sense to this collection of object and thus can be trated as one
single unit
Terms example in DDD
Advantage and disadvantages
• Communication easier(with
common language ubiquitous
language)
• Flexible (As the system was build
keeping in mind the business
domain)
• Maintainable( as to way how
domain model are build
modularity and encapsulation)
• Require strong domain
expertise(require frequent
expertise and regular
communication between expert
and developer)
• Not suited for short team
project or no much complexity
Example