The document discusses the traditional approach to software development and some of its shortcomings. It then introduces Domain-Driven Design (DDD) as an alternative approach that focuses on designing the system around the problem domain from the top-down rather than the bottom-up. Some key DDD concepts discussed include ubiquitous language, core domain, bounded contexts, entities, value objects, aggregates and aggregate roots, and persistence ignorance. The document uses examples from designing a residential building to help explain these DDD concepts.
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
Tonight I presented on Domain Driven Design to the Alt.Net group in Sydney at the invite of Richard Banks.
As a follow up, attached are the slides I used, feel free to distribute and use on the Creative Commons Licence
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
Domain-Driven Design is an approach to modelling business complexity explicitly in your software. This deck of slides runs through the key concepts focusing on both the strategic and tactical aspects of DDD.
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
A Practical Guide to Domain Driven Design: Presentation Slidesthinkddd
Tonight I presented on Domain Driven Design to the Alt.Net group in Sydney at the invite of Richard Banks.
As a follow up, attached are the slides I used, feel free to distribute and use on the Creative Commons Licence
Modelling a complex domain with Domain-Driven DesignNaeem Sarfraz
Domain-Driven Design is an approach to modelling business complexity explicitly in your software. This deck of slides runs through the key concepts focusing on both the strategic and tactical aspects of DDD.
Explain Domain-Driven Design, its main concepts and tools, and the Event Storming practice to highlight the importance of a good design and empower a team to start using it progressively.
Domain Driven Design (DDD) is a topic that's been gaining a lot of popularity in both the Java and .NET camps recently. Entities, value types, repositories, bounded contexts and anti-corruption layers -- find out what all the buzz is about, and how establishing a domain model can help you combat complexity in your code.
Richard Dingwall is a .NET developer and blogger with a passion for architecture and maintainable code.
He is currently working at Provoke Solutions as lead developer on a six-month project introducing test-driven development (TDD) and domain-driven design (DDD) to a large ASP.NET ERP system.
An hour-long talk given at Wellington .NET user group, Sept 23 2009.
Introducing Domain Driven Design - codemashSteven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Domain Driven Design main concepts
This presentation is a summary of the book "Domain Driven Design" from InfoQ.
Here is the link: http://www.infoq.com/minibooks/domain-driven-design-quickly
Microservices Pattern Language
Microservices Software Architecture Governance, Best Practices and Design Pattern
Decomposition Patterns
Decompose by Business Capability
Decompose by Subdomain
An Introduction to Domain Driven Design focusing on the concepts of Bounded Context, Strategic & Tactical Design, CQRS, Ubiquitous Language, Hexagonal Architecture, Event Sourcing, Task - based UIs
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
Talk given at Devoxx Belgium 2019.
===== Abstract =====
Are you in a mood for a brainstorm? Join this critical review of the major decisions taken in a typical enterprise application architecture and learn to balance pragmatism with your design goals. Find out how to do just-in-time design to keep as many use-cases as simple as possible.
The core purpose of this presentation is to learn to strike a **balance between pragmatism and maintainability** in your design. Without continuous refactoring, a simple design will inevitably degenerate into a Big Ball of Mud, under the assault of the new features and bugfixes.
On the other hand, the very highly-factored code can burden the take-off of the development and end up freezing the mindset in some rigid upfront design.
The end goal of this talk is to challenge you to rethink critically the architecture of your systems and seek ways to simplify it to match your actual needs, with a pragmatic mindset. "Architecture is the art of postponing decisions", said Uncle Bob.
This talk takes this idea further and explains an optimal mindset about designing enterprise applications: Evolving (Continuously Refactoring) a Pragmatic (Simple), Clean (aka Onion) Architecture, aiming to provide Developer Safety™️ and Comfort™️.
It’s the philosophy that Victor distilled over the past 5 years, designing and implementing 9 applications as IBM Lead Architect, and delivering training and advises to many other companies.
You’ll learn how to break data into pieces (Fit Entities, Value Objects, Data Transfer Objects), how to keep the logic simple (Facades, Domain Services, logic extraction patterns, Mappers, AOP), layering to enforce boundaries (keeping DTOs out of your logic, Dependency Inversion Principle), and many more, all in a dynamic, interactive and extremely entertaining session.
The Art of Unit Testing - Towards a Testable DesignVictor Rentea
Slides of the Talk I gave at Devoxx Belgium 2019.
=== Abstract ===
Focusing on the creative work without being terrified of breaking the existing behavior can make software development very addictive! Good automated tests can buy you that!
However, if your tests are not maintainable they may end up slowing you down and causing you painful headaches, compilation errors and spurious failures. To avoid that, your unit tests should be significant; expressive; clean; DRY; non-overlapping; and blazing fast. Writing good tests becomes the toughest challenge for any developer, no matter how battle-hardened: you need to balance risk with test maintenance costs, while looking out for test design smells that call for [risky] refactoring to drive your design towards a set of key principles (included:).
Principles that will end up shaping the way you craft the Production code itself. Because in the end, a good, clean design is more important than coverage%.
But testing gives you the best feedback to get there.
Grab a black coffee and join this snippet from Victor’s Pro Unit Testing #training, to learn about testing priorities, buggy tests, the shared @Before, Mocks vs Stubs and how to reduce them by "purifying" your logic, testing Legacy Code and refactoring @Spy-es out.
All of that in an entertaining, dynamic and memorable session.
Introducing Domain Driven Design - codemashSteven Smith
DDD provides a set of patterns and practices for tackling complex business problems with software models. Learn the basics of DDD in this session, including several principles and patterns you can start using immediately even if your project hasn't otherwise embraced DDD. Examples will primarily use C#/.NET.
Domain Driven Design main concepts
This presentation is a summary of the book "Domain Driven Design" from InfoQ.
Here is the link: http://www.infoq.com/minibooks/domain-driven-design-quickly
Microservices Pattern Language
Microservices Software Architecture Governance, Best Practices and Design Pattern
Decomposition Patterns
Decompose by Business Capability
Decompose by Subdomain
An Introduction to Domain Driven Design focusing on the concepts of Bounded Context, Strategic & Tactical Design, CQRS, Ubiquitous Language, Hexagonal Architecture, Event Sourcing, Task - based UIs
Evolving a Clean, Pragmatic Architecture - A Craftsman's GuideVictor Rentea
Talk given at Devoxx Belgium 2019.
===== Abstract =====
Are you in a mood for a brainstorm? Join this critical review of the major decisions taken in a typical enterprise application architecture and learn to balance pragmatism with your design goals. Find out how to do just-in-time design to keep as many use-cases as simple as possible.
The core purpose of this presentation is to learn to strike a **balance between pragmatism and maintainability** in your design. Without continuous refactoring, a simple design will inevitably degenerate into a Big Ball of Mud, under the assault of the new features and bugfixes.
On the other hand, the very highly-factored code can burden the take-off of the development and end up freezing the mindset in some rigid upfront design.
The end goal of this talk is to challenge you to rethink critically the architecture of your systems and seek ways to simplify it to match your actual needs, with a pragmatic mindset. "Architecture is the art of postponing decisions", said Uncle Bob.
This talk takes this idea further and explains an optimal mindset about designing enterprise applications: Evolving (Continuously Refactoring) a Pragmatic (Simple), Clean (aka Onion) Architecture, aiming to provide Developer Safety™️ and Comfort™️.
It’s the philosophy that Victor distilled over the past 5 years, designing and implementing 9 applications as IBM Lead Architect, and delivering training and advises to many other companies.
You’ll learn how to break data into pieces (Fit Entities, Value Objects, Data Transfer Objects), how to keep the logic simple (Facades, Domain Services, logic extraction patterns, Mappers, AOP), layering to enforce boundaries (keeping DTOs out of your logic, Dependency Inversion Principle), and many more, all in a dynamic, interactive and extremely entertaining session.
The Art of Unit Testing - Towards a Testable DesignVictor Rentea
Slides of the Talk I gave at Devoxx Belgium 2019.
=== Abstract ===
Focusing on the creative work without being terrified of breaking the existing behavior can make software development very addictive! Good automated tests can buy you that!
However, if your tests are not maintainable they may end up slowing you down and causing you painful headaches, compilation errors and spurious failures. To avoid that, your unit tests should be significant; expressive; clean; DRY; non-overlapping; and blazing fast. Writing good tests becomes the toughest challenge for any developer, no matter how battle-hardened: you need to balance risk with test maintenance costs, while looking out for test design smells that call for [risky] refactoring to drive your design towards a set of key principles (included:).
Principles that will end up shaping the way you craft the Production code itself. Because in the end, a good, clean design is more important than coverage%.
But testing gives you the best feedback to get there.
Grab a black coffee and join this snippet from Victor’s Pro Unit Testing #training, to learn about testing priorities, buggy tests, the shared @Before, Mocks vs Stubs and how to reduce them by "purifying" your logic, testing Legacy Code and refactoring @Spy-es out.
All of that in an entertaining, dynamic and memorable session.
A software editor in finance was facing the challenge to extend substantially the capabilities of its main application, despite 20 years of legacy in multiple technologies. In this talk, Cyrille Martraire will report on how DDD has been applied to capture deep models of the domain, within bounded contexts that emerged in the course of the project, and how DDD also helped to build a strategy for dealing with the legacy code.
The video is available on Skillsmatter website: http://skillsmatter.com/podcast/design-architecture/applying-ddd-legacy-app
Domain-Driven Design provides a set of principles and patterns that are useful for tackling complex software problems. In this session, we'll review a few DDD concepts and demonstrate how they can be applied within an ASP.NET MVC Solution to keep concerns separated and implementation details loosely coupled from business logic and your domain model.
Presented at FalafelCON 2014, San Francisco, September 2014
10 years after the release of the original book Domain Driven Design by Eric Evans we are seeing more and more applications built on the core concepts of DDD. Still, there is a long way to go before we fully grasp all its potential. First we need to change the way we do things in our projects. In this session I will show a possible implementation in C# that I've been using in many projects.
Following on from the success of last year, this annual event for London's architect community will have architectural innovation as a theme this year, and particularly CQRS. At the DDD eXchange we will feature leading thinkers and architects who will share their experience and Eric Evans is the programme lead.
Domain driven design is help as part of software development for proper deliver of software applications.
It will help on strategic planning of software design and delivery.
At the core, the job of a software developer is and has always been the same: writing good, elegant, sustainable and bug-free software that exceeds the expectations of your clients. But the context in which we do our job is changing and with it the skills required to be a great software developer. In this talk, I want to go through a couple of things that I think make the difference between a developer and a great developer. This includes some technical skills and practices, but also non-technical things that you might not consider relevant for a developer at first.
The importance to be Driven
There are many buzzwords and acronyms to describe how the software should be designed. TDD (Test Driven), BDD (Behaviour Driven), DDD (Domain Driven) are the most well known. In this speech we'll run thought all these techniques comparing each one of those with TDD and finding what are the common concepts. An exercise will show to the students how different the code will be using different design methodologies as driver.
Neil Perlin - We're Going Mobile! Great! Are We Ready?LavaConConference
In this session attendees will learn:
Technical options for going mobile, including responsive design, converting traditional online help to an app, and creating a “true” app using RMAD (Rapid Mobile App Development) tools. The pros and cons of each approach and some of the tools available for creating each option.
Anticipated changes in content creation practices and workflows including the elimination of local formatting, adoption of a “mobile first” philosophy, rethinking the role of tables, and more.
How company issues like terminology standardization, strategic benefit, politics, and the development of metrics and standards can help or hinder a move to mobile.
particular architecture that'd used on a recent system. An application can be developed with an amazing architecture, using the latest technologies and having the best interface, etc.
Get hands-on advice for rapid Agile prototyping in a product team.
You'll learn:
- How to determine the right depth and breadth for MVP prototypes.
- How to prioritize use cases for prototyping.
- How to elicit the right stakeholder and user feedback.
- How to correctly annotate prototypes for dev and QA.
Lviv IT Arena is a conference specially designed for programmers, designers, developers, top managers, inverstors, entrepreneur and startuppers. Annually it takes place on 2-4 of October in Lviv at the Arena Lviv stadium. In 2015 conference gathered more than 1400 participants and over 100 speakers from companies like Facebook. FitBit, Mail.ru, HP, Epson and IBM. More details about conference at itarene.lviv.ua.
Based on my observations, in IT we suffer from continuous collective amnesia and we are even proud of it.
For at least 50 years meanwhile, we struggle how to build systems, that are easy to understand, to maintain, to change and to operate in a reliable way. Each time we hit the wall again, we start to look for a new silver bullet on the horizon, strongly believing that it will solve the problem for good.
The key word is "new": "New" is good in our community, while "old" is bad, worthless, crap. We suffer from youthism, not only in recruiting, but in all areas. This way we discard any "old" knowledge, no matter if it is valuable or not. We separate by age, not by value.
Additionally we continuously lose our collective memory with every new generation that leaves university as they are also taught not to value anything old and instead only look for the new, shiny stuff.
While not all old knowledge is worth being preserved, admittedly, there is still a lot of valuable old knowledge available, offering answers to the problems that we face today - creating maintainable and reliable systems, dealing with distribution and tackling complexity, just to name a few of the challenges.
This presentation is a journey through some (very) old computer science papers that contain a lot of very valuable knowledge regarding the problems we face today. For each of the papers, some of the key ideas are presented and how they address our current challenges.
Of course, the voice track is missing and there are a lot more papers that would be worth being mentioned in this presentation. Still, I hope that also the slides alone will be of some value for you - and convince you a bit that not everything "old" in IT is automatically worthless ... ;)
Similar to How to Implement Domain Driven Design in Real Life SDLC (20)
How to Implement Domain Driven Design in Real Life SDLC
1. The way I learn DDD!
- Abdul Karim
Software Engineer
Dhaka, Bangladesh
2. What we traditionally do when we start a business application
development?
• We develop a SRS
• We read the SRS and find the functionalities.
• We breakdown tasks. In most of the cases the goal of the
breakdown is to come up with an estimation and plan of
works.
• We do the estimation.
• We distribute the works among team members.
• We go for a UI Mockup
• We design the database schema - sometimes by the team
leader or sometimes by the respective developer.
• We start coding.
3. • So? What’s wrong with this approach? We
have been doing good! Don’t we?
4. • The answer is YES and NO!
• Yes we are doing good in delivering our
projects to client.
• But NO! We are not doing good in maintaining
and extending our projects!
5. • Think about all of the projects you have worked last few years
in the traditional approach. Did you ever face any of the issues
below?
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 has 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.
6. I am sure you have been facing these issues
regularly though we have successfully finished
our project.
But do you know why?
7. The reason is, traditional approach do not guide us designing
the system in Up to Bottom fashion. Rather it tempted us to
design the system in Bottom-Up fashion.
See, when you design a system you need to know what as a
whole the application will do? What is the goal the client is
trying to achieve.
Then, from the top level goal you come up with different
smaller functionalities that will eventually allow the users to
achieve the top level goal.
But when you design in bottom-up approach, you first design
for the granular functionalities, and you have little or no
knowledge how this functionality will be used from the Top
level and how the Top level functionalities will actually look
like.
8. • Have you ever heard that a developer of your team is talking
like he does not have the domain knowledge of the whole
application? Perhaps yes!
• I think you can understand the reason. Cause, the design of
the application does not represent the domain of the system.
And so, developers know only the portions they worked.
• Developer has to depend on the box he knows only.
• This is Sad! Isn’t it?
9. • So, is traditional approach – “Designing the
application starting from database” a throw away
concept?
• Not really! But if you have a complex application to
develop, this bottom-up design approach do not
dictate you to come up with a proper object oriented
design.
• What is the solution then?
10. One of the solution might be DDD
DDD = DOMAIN DRIVEN DESIGN
12. What is DDD?
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.
- Wikipedia
13. Concepts to Cover in this Session:
• Understanding the Domain
• Ubiquitous Language
• Core Domain
• Model
• Contexts and Bounded Contexts
• Entities and Value Objects
• Aggregates and Aggregate Roots
• Persistence Ignorance
• Repository
• Domain Service
• Specification
14. In this session I will try to avoid to become too technical, rather I will try to
go through different concepts of DDD being close to the real world.
I will not show any code here. Cause I believe if you understand the
concept and starts thinking in DDD way, implementation is easy.
The toughest part is to tune our thinking process!
15. Understanding the Domain
• A sphere of knowledge, influence, or activity. The subject area to which the user
applies a program is the domain of the software.
-Wikipedia
So, do you get a feeling what is domain?
Can you tell what is the domain of the MyEdu project that we are working on?
Can you tell what is the domain of the famous website YouTube?
16. • In this session I would like to go through a real world example to give you
the feeling how to start analyzing your project driven by your domain. This
example may not be related with application development but as the goal
is to tune our thinking top to bottom manner, it will be useful.
• But Yes! We will go through the technical terms of DDD too!
17. • Let’s say you are engaged to design a building. The requirement is:
– You have a defined amount of land
– Your building will have 6 floor.
– Each floor will have 4 apartments.
• You need to design the building.
• So, What is our domain here?
• The domain is Building? It could be. But note that, if we consider Building as
our domain we may miss few granular detail for our requirement. The building
we are going to design must have design for apartments where people will
live. So, a general term “Building” can make us miss few detail.
• So?
18. • So, we may narrow down our domain to “Residential Building”.
• Now, when we talk about our work with engineers and also with the
people who assigned us to design the term “Residential Building” is more
meaningful for everybody concerned.
• Did you mark very small change in language here? The contractor is telling
you to design a building where there will be 4 apartments in each of the 6
floors. Now, if you send an engineer to the site telling him we will need to
construct a building there, they might not consider many attributes that a
residential building must have. On the other hand if you use the term
“Residential Building”, most likely he will come with a valid analysis.
• This is how we come to an “Ubiquitous Language”.
19. Ubiquitous Language
• The concept is simple, that developers and the business should share a
common language, that both understand to mean the same things, and
more importantly, that is set in business terminology, not technical
terminology.
More Example:
• Wrong language: The length and width ratio of the smaller bed rooms
would be 4:3.
• Correct language: The children's bed room’s length will be 20 ft and width
will be 15 ft.
Note, that to the owner of the building smaller room, ratio all these things
could be very technical terms. Rather it is easier for him to understand
children's room, guest room, living room etc. And explicit measurement is
more meaningful to him.
20. Ubiquitous Language
More Example:
Now, let’s talk about an example of a software perspective:
Wrong language:
In search functionality we will consider inflectional and thesaurus feature of sql server to
make the search more relevant. Additionally we will also exclude the stop words from the
search to make it more accurate.
Note that, your domain expert may not be a technical person and thus he may not
understand what you meant by the words “Inflectional”, “Thesaurus”, “Stop word” etc.
Correct language:
In the search functionality we will consider all the synonyms of the search phrase so that it
does not exclude relevant results. Moreover we will not differentiate any search word by it’s
number(singular or plural), tense, participle etc so that the result becomes more accurate.
Additionally as expected in any search, we will ignore all the noise words that do not have
any value in the search. Such noise words could be “am”, “but”, “where”, “about” etc.
21. Define Ubiquitous Language
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.
22. • Let’s come back to our “Residential Building” domain.
• Look, we can proceed with the residential building design as a single task
and address the whole thing together. But will it really be very wise way to
do?
• Note that if we just consider this a single unit of work we may miss many
things. Designing a building is related so many things. For example: We
need to consider ventilation, utility, parking space, community space etc.
• Now you see, different other contexts are coming up.
• This is how the concept “Context” and “Bounded Context” comes up in
Domain Driven Design.
23. Not all of a large and complex system
will be well designed.
45. Strategy
• Draw a Context Map.
• Work with business leadership to define Core
Domain.
• Design a platform that supports work in the
Core Domain.
• Work with management to give freedom to
the Core Domain Platform Context.
• Develop and model in the Core Domain.
46. Define Model
model A system of abstractions that describes
selected aspects of a domain and can be used
to solve problems related to that domain.
47. Define Model
model A system of abstractions that describes
selected aspects of a domain and can be used
to solve problems related to that domain.
48. Define Model
model A system of abstractions that describes
selected aspects of a domain and can be used
to solve problems related to that domain.
49. Contexts and Bounded Contexts
A Bounded Context can be considered as a miniature
application, containing it’s own Domain, own code and persistence
mechanisms. Within a Bounded Context, there should be logical
consistency, each Bounded Context should be independent of any other
Bounded Context.
50. Contexts and Bounded Contexts
More Example:
Think of an e-Commerce system. Initially you can tell it is an application of
shopping context. But if you look more closely, you will see there are other
contexts too. Like: Inventory, Delivery, Accounts etc.
Dividing a large application among different bounded contexts properly
will allow us to make our application more modular, will help us to
separate different concerns and will make the application easy to manage
and enhance.
Each of these Bounded Contexts has a specific responsibility, and can
operate in a semiautonomous fashion. By splitting these apart it becomes
more obvious where logic should sit, and we can avoid that BBOM (Big ball
of mud)
51. • What is BBOM?
A Big Ball of Mud is a haphazardly structured, sprawling, sloppy, duct-tape-and-
baling-wire, spaghetti-code jungle. These systems show unmistakable signs of
unregulated growth, and repeated, expedient repair. Information is shared
promiscuously among distant elements of the system, often to the point where
nearly all the important information becomes global or duplicated. The overall
structure of the system may never have been well defined.
- Brian Foote and Joseph Yoder, Big Ball of Mud. Fourth Conference on Patterns
Languages of Programs (PLoP '97/EuroPLoP '97) Monticello, Illinois, September 1997
Our all time objective should be to avoid BBOM
52. • Again with the “Residential Building Domain”
• So, we could have several bounded contexts:
– Electricity supply
– Car parking
– Apartment
– Etc.
• Let’s talk about the apartment. The apartment is basically a combination
of different rooms. The rooms have different elements inside. like
windows, doors etc.
• Now I have 2 questions about the windows of the room.
53. • Question1: Can you imagine a window without a room?
• Question2: Does a window have any identity without the room it is
residing in?
• Answering the question will expose the following concepts of DDD in-front
of you:
1. Entity.
2. Value Object.
3. Aggregates & Aggregate root.
54. Entity
“This is my Entity, there are many like it, but this one is mine”
The key defining characteristic of an Entity is that it has an Identity – it is unique
within the system, and no other Entity, no matter how similar is the same Entity
unless it has the same Identity.
Examples:
1. My bed room in the apartment
2. Contract in Facebook.
55. Value Object
The key defining characteristic of a Value Objects is that it has no Identity.
Ok, perhaps a little simplistic, but the intention of a Value Object is to represent
something by it’s attributes only.
Two VOs may have identical attributes, in which case they are identical. They don’t
however have any value other than by virtue of their attributes.
Another aspect common to VOs is that they should probably be immutable, once
created they cannot be changed or altered. You can create a new one, and as they
have no identity, that is just the same as changing another one.
Example:
1. Windows in the rooms
2. Address of any person in Assess of MIST or other apps.
3. SearchCriteria in MIST Query Analyzer search engine.
Note: A value object can become an entity depending on the situation. Can you
find a scenario when SearchCriteria of MIST Query Analyzer can be an entity?
56. • So, now we know what is entity and what is value object in DDD.
• In domain driven design entities and value objects can exist
independently. But in some cases the relation can be such that, an entity
or VO has no value without its context.
• For example:
1. A window can only be defined if there is a room.
2. An order note can only exist if an order is placed.
3. A question detail can only be there if a question is asked.
Very simple isn’t it? Believe me, now you know what is Aggregates and
what is Aggregate root.
57. • we have already discussed the concept of aggregate and
aggregate root.
• In the examples we have given:
– Room, Order and Question are our aggregate roots.
– On the other hand window, order note and question detail
are our aggregates.
58. Aggregate and Aggregate Root
“A cluster of associated objects that are treated as a unit with regard to
data changes.”
All objects of the clusters should be treated as aggregate.
All external access to the cluster is through a single root Entity. This root
entity is defined as aggregate root.
59. • Example:
• A question detail should no way be saved unless the corresponding
question is saved.
• A question detail should no way be retrieved unless the corosponding
question is retrieved.
• Here Question is the Aggregate root and Question Detail is the aggregate.
Aggregates and Aggregates Root are very important concept of DDD. Do
you have any questions on this?
60. Persistence Ignorance
So far we have talked about
domain, objects/entities, contexts, aggregates etc.
What about the Database? Is that something we have missed?
Isn’t it something should come in the design?
• The answer is NO!
DDD is a persistence ignorant approach.
61. Persistence Ignorance
• In domain driven design your objective is to create a model of
the domain. You need to identify what are the items (objects)
you need to have to accomplish the desired functionalities of
your application domain. You need to identify the
relationships among different objects and how they interact
among themselves. You need to find if the business goal of
your client is achievable using your domain model.
• Where is the existence of database here? You do not need to
know how and where the data of your domain will persist or
even if the data do need to persist while you do the model of
the domain.
62. Persistence Ignorance
• This ignorance about your persistence medium will make your
domain model free from any coupling with the persistence layer of
the application. This will eventually separate the concerns of the
persistence and its communication mechanism from your domain
model. In result your application will be free from coupling with any
data store and will be very easily unit testable.
• But Yes! In a real application you do need to have a database. But
your domain model will have no knowledge about that. All it will
know is the “Repository” which will eventually manage your
application’s persistence concern.
• It will be more clear as I will go little more detail about repository.
63. Repository
• Tell me what is the meaning of the English word “Repository”?
Repository commonly refers to a location for storage, often for safety or
preservation.
-Wikipedia
As we already told that your domain model will not know any database.
What it will know is, there is a repository in the system and that repository
will be responsible to store your data and to retrieve your data. It is now
way a concern of your domain model how and where data will persist.
So, it can be Sql server, oracle, xml, text file or anything else.
I hope now you got a sense what a repository means in DDD.
64. Repository
• Let’s become little more technical.
Repository Mediates between the domain and data mapping using a
collection-like interface for accessing domain objects. It is more like a
facade to your data store that pretend like a collection of your domain.
Repository Is Not A Data Access Layer
Note that repository doesn’t talk in terms of “data”, it talks in terms of Aggregate Roots. You
can tell your Repository to add an Aggregate Root into it’s collection, or you can ask it for a
particular Aggregate Root. When you remember that Aggregate Roots may comprise one or
many Entities and Value Objects, this makes it fairly different to a traditional DAL that returns
you back a set of rows from your database tables.
65. Repository
• Implementation strategy:
1. 1st of all you will have an interface - IRepository that should be generic.
2. You will have an abstract implementation of the IRepository interface
3. You will have interface for your persistence mechanism like for Nhibernate -
INhRepository this will inherit from IReposiroty
4. You will have implementation of INhReposiroty in a class like “NhReposirory”.
5. Finally you may have a generic implementation of the repository that will have default
implementations of all the common methods of the repository.
6. Like NHGenericRepository that inherits from NhRepository and implments
IGenericNhReposirtory.
7. Your application will use service locator to find which repository the application will use.
I know the above implementation strategy may not be clear to all of you. But to explain
the repository implementation in more detail with example is out of the scope of this
presentation. We may need separate session on this. If you review the code of IWM
Entityframework GenericRepository you will find a super implementation of this
concept.
66. Domain Service
• Domain service is another important concept of DDD.
if Entities and Value Objects are the “things” in our Domain, the Services
are a way of dealing with actions, operations and activities.
Shouldn’t Logic Be on the Entities Directly?
Yes, it really should. We should be modeling our Entities with the logic that
relates to them and their children. But, there are occasions when we need
to deal with complex operations or external responsibilities or may be we
need to expose the actions of the aggregate roots to the external world.
This is why creating a domain service for different aggregate root is a good
idea. You can consider the domain services as façade layer of the business
logics and operations of your domain.
67. Specification
• A design pattern
• A Specification is, in simple terms, a small piece of logic that sits on it’s
own and gives an answer to a simple question … “does this match?”
• Example:
• We have a Customer, and we want to be able check if they are eligible for
a discount on a Product. If we were to put a method on the Customer
entity, for example .IsEntitledToDiscountPrice(Product) we start to couple
our entities tightly together, and as the number of questions we want to
ask of our entity increases, the more polluted its interface becomes.
The Solution here is Specification.
68. Specification
Code copied from: Domain_Driven_Design_-_Step_by_Step by Casey Charlton