As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I'm learning about Domain Driven Design, however there are some practical issues that are confusing to me that I think seeing some good samples might clear up.
Does anyone know of some good working code samples that do a good job of modelling basic DDD concepts?
Particularly interested in
An illustrative Domain Model
Repositories
Use of Domain/Application Services
Value Objects
Aggregate Roots
The difficulty with DDD samples is that they're often very domain specific and the technical implementation of the resulting system doesn't always show the design decisions and transitions that were made in modelling the domain, which is really at the core of DDD. DDD is much more about the process than it is the code. (as some say, the best DDD sample is the book itself!)
That said, a well commented sample app should at least reveal some of these decisions and give you some direction in terms of matching up your domain model with the technical patterns used to implement it.
You haven't specified which language you're using, but I'll give you a few in a few different languages:
DDDSample - a Java sample that reflects the examples Eric Evans talks about in his book. This is well commented and shows a number of different methods of solving various problems with separate bounded contexts (ie, the presentation layer). It's being actively worked on, so check it regularly for updates.
dddps - Tim McCarthy's sample C# app for his book, .NET Domain-Driven Design with C#
S#arp Architecture - a pragmatic C# example, not as "pure" a DDD approach perhaps due to its lack of a real domain problem, but still a nice clean approach.
With all of these sample apps, it's probably best to check out the latest trunk versions from SVN/whatever to really get an idea of the thinking and technology patterns as they should be updated regularly.
Not source projects per say but I stumbled upon Parleys.com which has a few good videos that cover DDD quite well (requires flash):
Improving Application Design with a Rich Domain Model
Get Value Objects Right for Domain Driven Design (unavailable)
I found these much more helpful than the almost non-existent DDD examples that are currently available.
.NET DDD Sample from Domain-Driven Design Book by Eric Evans can be found here: http://dddsamplenet.codeplex.com
Cheers,
Jakub G
Check out Project Silk. Not only does it demonstrate DDD but other cutting edge patterns. This is an excellent resource for any Web Developer. A full overview of the project can be found on MSDN.
This is a good example based on domain driven design and explains why it is important to have separate domain layer.
Microsoft spain - DDD N Layer Architecture
ddd-cqrs-sample is also a good resource. Written with Java, Spring and JPA.
Updated link:
https://github.com/BottegaIT/ddd-leaven-v2
Code Camp Server, Jeffrey Palermo's sample code for the book ASP.NET MVC in Action. While the book is focused on the presentation layer, the application is modeled using DDD.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I often read that you should not do DDD when the team has no access to a domain expert.
But what are the alternatives to DDD if the domain is not trivial but there is no domain expert available and the team only has access to a proxy domain expert or only to the product owner.
Shouldn't the team in this case create a common language accross the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc?
I understand that DDD is not a whole or nothing and that it is not describing an architecture
but a design methodology. But doesn't it make scence to use the tactical patterns and strategic design of DDD in case of a complex domain just because a domain expert is not available? Which part of DDD would I NOT use when no domain expert is available?
What you actually do need is a domain expert as a role, not necessarily as a concrete physical person (other than one or more development team member(s)). Having a 'real' domain expert is desirable, but not always possible. In such a case, the development team has to accumulate expert domain knowledge itself - not perfect, I know, but perfectly possible (and not so uncommon in practice).
First, I haven't read that you should not do DDD when the team has no access to a domain expert.
The main advantage of the Domain Model and Domain-Driven Design is usage of Ubiquitous Language. It is "a common, rigorous language between developers and users".
It is used to solve misunderstandings between developers and business.
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design. The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, ...
(c) Eric Evans, DOMAIN-DRIVEN DESIGN
And either development team or business client should use the same vocabulary working on a project.
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Recognize that a change in the language is a change to the model.
(c) Eric Evans, DOMAIN-DRIVEN DESIGN
In your case it is enough to have "access to a proxy domain expert or only to the product owner".
In Scrum process Product Owner (PO) is a bridge between development team and stakeholders.
It is common when development team enforces business to use Ubiquitous Language, when developers who do business analysis and business people/ PO form this language together.
Sometimes business has several terms for single one 'entity', or 'process', or 'feature' and it is a challenge to select the correct one term.
Second, Since it is team's responsibility to make architectural decisions and design application, they can "create a common language across the team, create a domain model within bounded contexts, use aggregates and aggregate roots to enforce business constraints, use repositories to ensure persistence ignorance for the model, etc" when it is reasonable.
Third, I think that decision on doing or not doing DDD depends on requirements for software and doesn't depend on domain expert availability.
Can somebody please explain (in succinct terms) what exactly is domain driven design? I see the term quite a lot but really don't understand what it is or what it looks like. How does it differ from non-domain driven design?
Also, can somebody explain what a Domain Object is? How does domain differ from normal objects?
EDIT:
As this seem to be a top result on Google and my answer below is not, please refer to this much better answer:
https://stackoverflow.com/a/1222488/1240557
OLD ANSWER (not so complete :))
In order to create good software, you have to know what that software
is all about. You cannot create a banking software system unless you
have a good understanding of what banking is all about, one must
understand the domain of banking.
From: Domain Driven Design by Eric Evans.
This book does a pretty good job of describing DDD.
Register to download a summary of the book.
Domain Driven Design is a methodology and process prescription for the development of complex systems whose focus is mapping activities, tasks, events, and data within a problem domain into the technology artifacts of a solution domain.
The emphasis of Domain Driven Design is to understand the problem domain in order to create an abstract model of the problem domain which can then be implemented in a particular set of technologies. Domain Driven Design as a methodology provides guidelines for how this model development and technology development can result in a system that meets the needs of the people using it while also being robust in the face of change in the problem domain.
The process side of Domain Driven Design involves the collaboration between domain experts, people who know the problem domain, and the design/architecture experts, people who know the solution domain. The idea is to have a shared model with shared language so that as people from these two different domains with their two different perspectives discuss the solution they are actually discussing a shared knowledge base with shared concepts.
The lack of a shared problem domain understanding between the people who need a particular system and the people who are designing and implementing the system seems to be a core impediment to successful projects. Domain Driven Design is a methodology to address this impediment.
It is more than having an object model. The focus is really about the shared communication and improving collaboration so that the actual needs within the problem domain can be discovered and an appropriate solution created to meet those needs.
Domain-Driven Design: The Good and The Challenging provides a brief overview with this comment:
DDD helps discover the top-level architecture and inform about the
mechanics and dynamics of the domain that the software needs to
replicate. Concretely, it means that a well done DDD analysis
minimizes misunderstandings between domain experts and software
architects, and it reduces the subsequent number of expensive requests
for change. By splitting the domain complexity in smaller contexts,
DDD avoids forcing project architects to design a bloated object
model, which is where a lot of time is lost in working out
implementation details — in part because the number of entities to
deal with often grows beyond the size of conference-room white boards.
Also see this article Domain Driven Design for Services Architecture which provides a short example. The article provides the following thumbnail description of Domain Driven Design.
Domain Driven Design advocates modeling based on the reality of
business as relevant to our use cases. As it is now getting older and
hype level decreasing, many of us forget that the DDD approach really
helps in understanding the problem at hand and design software towards
the common understanding of the solution. When building applications,
DDD talks about problems as domains and subdomains. It describes
independent steps/areas of problems as bounded contexts, emphasizes a
common language to talk about these problems, and adds many technical
concepts, like entities, value objects and aggregate root rules to
support the implementation.
Martin Fowler has written a number of articles in which Domain Driven Design as a methodology is mentioned. For instance this article, BoundedContext, provides an overview of the bounded context concept from Domain Driven Development.
In those younger days we were advised to build a unified model of the
entire business, but DDD recognizes that we've learned that "total
unification of the domain model for a large system will not be
feasible or cost-effective" 1. So instead DDD divides up a large
system into Bounded Contexts, each of which can have a unified model -
essentially a way of structuring MultipleCanonicalModels.
You CAN ONLY understand Domain driven design by first comprehending what the following are:
What is a domain?
The field for which a system is built. Airport management, insurance sales, coffee shops, orbital flight, you name it.
It's not unusual for an application to span several different domains. For example, an online retail system might be working in the domains of shipping (picking appropriate ways to deliver, depending on items and destination), pricing (including promotions and user-specific pricing by, say, location), and recommendations (calculating related products by purchase history).
What is a model?
"A useful approximation to the problem at hand." -- Gerry Sussman
An Employee class is not a real employee. It models a real employee. We know that the model does not capture everything about real employees, and that's not the point of it. It's only meant to capture what we are interested in for the current context.
Different domains may be interested in different ways to model the same thing. For example, the salary department and the human resources department may model employees in different ways.
What is a domain model?
A model for a domain.
What is Domain-Driven Design (DDD)?
It is a development approach that deeply values the domain model and connects it to the implementation. DDD was coined and initially developed by Eric Evans.
Culled from here
Here is another good article that you may check out on Domain Driven Design. if your application is anything serious than college assignment. The basic premise is structure everything around your entities and have a strong domain model. Differentiate between services that provide infrastructure related things (like sending email, persisting data) and services that actually do things that are your core business requirments.
Hope that helps.
As in TDD & BDD you/ team focus the most on test and behavior of the system than code implementation.
Similar way when system analyst, product owner, development team and ofcourse the code - entities/ classes, variables, functions, user interfaces processes communicate using the same language, its called Domain Driven Design
DDD is a thought process. When modeling a design of software you need to keep business domain/process in the center of attention rather than data structures, data flows, technology, internal and external dependencies.
There are many approaches to model systerm using DDD
event sourcing (using events as a single source of truth)
relational databases
graph databases
using functional languages
Domain object:
In very naive words, an object which
has name based on business process/flow
has complete control on its internal state i.e exposes methods to manipulate state.
always fulfill all business invariants/business rules in context of its use.
follows single responsibility principle
DDD(domain driven design) is a useful concept for analyse of requirements of a project and handling the complexity of these requirements.Before that people were analysing these requirements with considering the relationships between classes and tables and in fact their design were based on database tables relationships it is not old but it has some problems:
In big projects with complex requirements it is not useful although this is a great way of design for small projects.
when you are dealing with none technical persons that they don,t have technical concept, this conflict may cause some huge problems in our project.
So DDD handle the first problem with considering the main project as a Domain and splitting each part of this project to small pieces which we are famous to Bounded Context and each of them do not have any influence on other pieces.
And the second problem has been solved with a ubiquitous language which is a common language between technical team members and Product owners which are not technical but have enough knowledge about their requirements
Generally the simple definition for Domain is the main project that makes money for the owners and other teams.
I do not want to repeat others' answers, so, in short I explain some common misunderstanding
Practical resource: PATTERNS, PRINCIPLES, AND PRACTICES OF DOMAIN-DRIVEN DESIGN by Scott Millett
It is a methodology for complicated business systems. It takes all the technical matters out when communicating with business experts
It provides an extensive understanding of (simplified and distilled model of) business across the whole dev team.
it keeps business model in sync with code model by using ubiquitous language (the language understood by the whole dev team, business experts, business analysts, ...), which is used for communication within the dev team or dev with other teams
It has nothing to do with Project Management. Although it can be perfectly used in project management methods like Agile.
You should avoid using it all across your project
DDD stresses the need to focus the most effort on the core subdomain. The core subdomain is the
area of your product that will be the difference between it being a success and it being a failure. It’s
the product’s unique selling point, the reason it is being built rather than bought.
Basically, it is because it takes too much time and effort. So, it is suggested to break down the whole domain into subdomain and just apply it in those with high business value. (ex not in generic subdomain like email, ...)
It is not object oriented programming. It is mostly problem solving approach and (sometimes) you do not need to use OO patterns (such as Gang of Four) in your domain models. Simply because it can not be understood by Business Experts (they do not know much about Factory, Decorator, ...). There are even some patterns in DDD (such as The Transaction Script, Table Module) which are not 100% in line with OO concepts.
I believe the following pdf will give you the bigger picture. Domain Driven Design by Eric Evans
NOTE: Think of a project you can work on, apply the little things you understood and see best practices. It will help you to grow your ability to the micro service architecture design approach too.
Get an organization wide understanding of the problem domain by
developing a ubiquitous language (a common mental model) per sub-problem-domain.
Use that language as close as possible in solution domains (code).
Only then choose technologies.
Don't be technology driven but problem domain or business driven.
I have found quite a few material (books and other stuff online) on how to make UML diagrams. So now I understand UML and the diagramming (with a tool).
However, where I am stuck is the approach / methodology. My hunt for approach / methodology always leads to how to use UML and which diagram fits where. Frankly my intent is to know how to start the journey from putting down the domain understanding (and how) to drafting the blueprint of the system that is ready for the use of developers.
I really don't care if it is UML (good if it is so) or not. I should be able to communicate the target application's domain understanding, it's analysis and eventually it's intended design in as clear terms as possible.
I think there is no Cast in Stone way of doing this, however, I am looking for potential approaches / methodologies. Please share pointers to any books / training material that is available for the purpose.
Here are a few resources that may help:
Domain Driven Design Quickly (Free summary of Domain Driven Design)
Domain Driven Design
These resources deal with gathering the knowledge of the Domain from domain experts, coming up with terms that are ubiquitous for all parties involved, and then designing the programming model to suit.
Additionally, since you mention UML, and if you haven't come across the following book yet, I highly recommend it:
UML Distilled 3rd Edition
Lastly, in more general terms, I would look further into Agile Development Methodologies.
This is one thing that has been bugging me for a while about DDD. I can clearly see the benefits of the approach when dealing with non-technical business domains with complex models and lots of interaction required between technical people and non-technical domain experts.
However, what about when the 'domain' in question is technical?
For instance, situation A) take a web start-up. Imagine they are trying to accomplish something quite complicated (say a facebook clone), but almost all of the staff are technical (or at least have strong technical understanding).
What about situation B) A similar situation, but with a slightly less ambitious project, and a lone developer trying to create somthing with an elegant architecture.
I'd be really interested to hear what people have to say. What I'm really trying to get to the meat of, is where the benefits of DDD lie, what the downsides might are, and at what point one outweighs the other...
DDD is really just an elaboration of the design pattern Fowler calls Domain Model in Patterns of Enterprise Application Architecture. In that book, he compares Domain Model to other ways of organizing code, such as Transaction Script, but it is clear that he prefers Domain Model over other alternatives for all but the simplest of applications. I do, too.
DDD simply expands greatly on the original concept of a Domain Model and provides tons of guidance on how we should analyze and model our domain in a way that will be beneficial to ourselves as developers.
If the Domain in question is complex, then a Domain model (and hence DDD) is a good choice. It doesn't really matter whether the Domain is business-oriented or more technical in nature. In his book Domain-Driven Design, Eric Evans starts by describing how the DDD techniques helped him model a Printed Circuit Board application. That is surely a technical Domain, if any!
In my current work, we are using DDD to model an application that deals with Claims-based identity - another very technical Domain.
DDD is really just about dealing with complexity in sofware, and this is also the subtitle of Evans' book: "Tackling Complexity in the Heart of Software."
Evans suggest using Domain Driven Design when :
Domain Complexity > Technical Complexity
If your domain is simple but you have many technical limitations (technology choice, performance restrictions etc), do not use DDD.
If your domain in complex, do DDD, put the domain as the core of your system, and move any other concern outside (persistence, performance, technology concerns).
I don't really have a great answer for you, but I can say from my perspective as an outsider to DDD with an interest in DDD I've seen technical domain concepts / drivers creep into the the DDD conversation as first class concepts. A good example of this would be that some people are advocating for technical / infrastructure bounded contexts. The best example I can think of is Greg Young's architecture where he considers reads a bounded context and transactional writes another bounded context. In general I think things like this are "domain constructs" (my term... forgive me if I must mutilated a real DDD term). It's similiar to objects in the OO world that don't model something in the real world but are fully flushed out objects.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Can somebody point me towards a 'complete' DDD example developed on the .NET platform. Most of the examples I find feel 'incomplete'.
I'd really like to see the DDD principles in action.
You could try the code that is built as part of the .NET Domain-Driven Design with C#: Problem - Design - Solution book.
The code is freely available from Codeplex here and also on the book's website, and is a fairly feature complete application demonstrating DDD with C#.
From the codeplex site:
The book is one large case study of a real-world application, named SmartCA, which is a smart client application implemented with the latest .NET technologies and following DDD principles.
.NET DDD Sample from Domain-Driven Design Book by Eric Evans can be found here: http://dddsamplenet.codeplex.com
Szymon (search google for: simon-says-architecture dotCOM) is updating source code almost on daily basis. The last release is from 28th Jan 2010.
Cheers,
Jakub G
These are ASP.NET MVC sample applications -
here
Worked well enough for me.
Here it`s possible to get book about DDD -
here
(use www.bugmenot.com, if you dont want to register there).
edit
'ddd quickly...' ain`t good enough. look for 'ddd tackling complexity in the heart of software'.
Try this:
Domain Oriented N-Layered .NET 4.0 Sample App.
By Microsoft - Spain
Using .NET 4.0 C#, Entity Framework 4.0
Implementing typical DDD architecture & desing patterns
Sample-App Current state - BETA Version. (V0.9 is compatible with VS.2010 RTM, final .NET 4.0 version, Silverlight 4.0, UNITY 2.0 and PEX&MOLES V0.92)
http://microsoftnlayerapp.codeplex.com/