domain driven design is - github pagesjoshilewis.github.io/elen7045/ahmed's ddd...
TRANSCRIPT
Domain Driven Design IS
An architectural methodology for evolving a software system
that closely aligns to business requirements
Domain Driven Design IS
• Domain First • Focus on the Object Model • Focus on Object-Oriented Design • Works well with other *DD methods to:
• Reduce Complexity • Increase Maintainability
Domain Driven Design IS NOT
l A silver bullet l A panacea for all your troubles l An easy path to follow l Always the best solution
l And most importantly, it is not focused on the How, but the What and Why
The Domain Vision Statement
l A shared understanding of what it is you are actually trying to create
l Should be brief, written in clear English and understood by business and tech people alike
l Should be factual, realistic, honest l Should avoid superlatives and marketing
speak l Should avoid technical and implementation
details
Domain
l A Domain is a Sphere of Knowledge, Influence or Activity
l A Domain is represented by the Ubiquitous Language
l A Domain encapsulates a Domain Model
l A Domain lives within a Bounded Context
The Ubiquitous Language
l A major reason for failure of software projects is a failure of people, the failure to communicate
l The Ubiquitous Language is a shared language between the business and the development teams
Domain Experts
l Domain Experts are the primary point of contact the development teams have with the business
l They are the Experts on their part of the business, not just users of the system
l They should have deep knowledge of the subject Domain
Domain Model
l A Domain Model is a representation of the relationships between the Entities and Value Objects in your Domain
l It may look similar to UML or a class relationship diagram, but it is not one
l The Domain Model should be recognisable and understandable by the business
Building Blocks
Entities
l Entities are the “things” within your Model
l An Entity is defined by being unique, and uniquely identifiable through time
l They have identity, state and behaviour l E.g. Person, Account
Value Objects
l Value Objects are the “things” within your model that have no uniqueness
l They are equal in all ways to another Value Object if all their properties match
l Value Objects are interchangeable
Aggregates
l “An aggregate is a collection of items that are gathered together to form a total quantity” – Wikipedia
l Provides a boundary to manage invariants
l An Aggregate Root is the root item containing a number of parts that form a whole
Services
l Some concepts or operations from the domain model are not naturally modelled as objects
l These operations often involve many domain objects and co-ordinate their behaviour
Factories
l Abstract away the creation of aggregates so objects can be simpler and focused
l Factories manage the beginning of the life cycle of some aggregates
Persistence Ignorance
l “There Is No Database” l DDD uses the Repository pattern to
create Persistence Ignorance l A Repository represents itself as an in-
memory list of items l Repositories are specific to Aggregate
Roots, not to Entities
Repositories
l Abstraction over data access l Repositories manage the middle and
end of the life cycle l Repositories might delegate persistence
responsibilities to object-relational mappers for retrieval of objects
l 1 Aggregate : 1 Repository
Bounded Contexts
l When you have multiple models you should consider Bounded Contexts
l Each BC is a self contained “mini application” containing it’s own model, persistence and code base
l To map between BCs you use a Context Map
Factors For Success of DDD
l Your domain is not trivial l You have access to Domain Experts l You have an iterative process l You have a skilled and motivated team
Messaging Architectures
l DDD is ideally suited to Message Based Architectures
l DDD is ideally suited to Commands and Events
l DDD is ideally suited to providing multiple autonomous systems that are loosely coupled
Command Query Responsibility Separation (CQRS)
l Bertrand Meyer principle of CQS: every method should either be a command that performs an action, or a query that returns data to the caller
l At an architectural level this means: either issue commands, or issue queries, but never both
l And, query from a separate source from your domain commands
CQRS in a Picture
