I'm analyzing a fairly enterprise resource planning software and because an ERP covers many areas from accounting to sales and CRM I have chosen to use Domain Driven Design. Now I have two questions :
What are main APPLIED (not in theory) resources to start DDD?
How can I find out for example to which Domain or Module an "Invoice"
belongs ? Does it belongs to "Accounting" or "Sales"?
There may be many examples of such situation where I get confuse when separating Entities and Domains...
How can I overcome this problem ?
I'm not a DDD authority in any way, but here's my 2 cents
1) Have you read the blue bible? The examples there are taken from Eric Evans experience building a real shipping platform. I haven't seen any other published example as big as the one in the book.
2) Invoice can belong to both, but it will probably mean different things on each domain, in sales it will be linked to an order, payment and so on; in Accounting it will be linked to a Ledger and an Account.
You won't find a unique domain to solve the whole ERP problem. I'm not experienced with ERPs, but knowing sales and CRM, I would say that you might find 15+ different domains, some will be tiny frameworks, some will be solve chunky parts of the problem.
About your confusion: What I've done in the past is to find questions related to DDD here in SO (some are really enlightening) and read blogposts from people who know quite a lot about DDD - lostechies have quite a few good blogposts about DDD.
There is two resources i would recommend that use DDD in practice: the first one is the one and only famous book Applying Domain-Driven Design and Patterns_ With Examples in C# and .NET.pdf, and the other one is dotNET Domain Driven Design with C# - Problem - Design - Solution.pdf but they both assume you have read Eric Evan's book first.
i don't think anyone is qualified to answer the second question very well, and most people will say it depends on context and you particular application. the hard truth is that DDD is about design and it requires sophisticated skills (it is not easy). so i will suggest you develop your code incrementally with backing tests so you could change you design when the right moment comes (that what eric refers to as a Breakthrough).
Related
Im new to learn DDD concept and i cant understand something.
1-What difference between Context Map and Bounded Context and SubDomain?
2-How to recognize relation between Bounded Context ?
As said in the comment, this is a wide subject, and very important in DDD. It is the strategic part of DDD. Anyway I will try to answer your questions with an overall explanation:
DDD is about understanding and distilling the domain of the problem we want to solve. It is a continuous process of learning about the domain, talking to the domain experts. All people (developers, business people, etc) speak the same language. This language is used everywhere (conversations, documentation, source code, ...). It is called the Ubiquitous Language (UL).
The problem domain may have different areas of functionality, which would be domains too. They are the subdomains. So a subdomain is a subset of the problem domain. It is like splitting the problem into smaller subproblems, and a subdomain would be the domain of a subproblem. There are 3 kinds of subdomains:
Core: The point of distillation is to discover the subdomain that has value for the business, i.e., the one that will make your product better than others of the same kind. Such subdomain is the "core subdomain". For example, in "project management", the "task assignement" would be core.
Supporting: It is specialized in some business aspect that helps the core functionality. For example, in "project management", a "calendar" (for marking tasks delivery dates).
Generic: Functionality that maybe needed by any kind of application. For example, authentication and authorization of users.
Subdomains belong to the problem space.
To solve the problem, you model the subdomains, and you create bounded contexts (BCs). In practice, a BC is an autonomous application that contains the software model of a subdomain. A BC has its own UL. It is the context on which a term of the UL has a meaning. UL and BCs are the most important things in DDD. UL drives the BCs identification.
Ideally, you should align 1:1 the subdomains of the problem space with the BCs of the solution space, i.e., you should have a BC for each subdomain.
A team can develop one or more BCs, but a BC should be developed by just one team.
BCs belong to the solution space.
Context Map: It is a drawing that shows the BCs, and the relationships among them. Every relationship is classified in one of the following patterns:
Partnership
Shared Kernel
Customer-Supplier
Conformist
Anticorruption Layer
Open Host Service
Published Language
Separate Ways
Big Ball of Mud
Recognizing which pattern to apply in a relationship it will depend on the particular case you have. Some things that you have to consider are:
The 2 teams collaborate together.
One of the teams doesn't care about the other one.
The teams can negotiate.
The teams are independent.
Changes on a model (upstream) affects to the other model (downstream).
As #Augusto mentioned, this is a couple of chapters in the blue book, but here goes.
The domain model is found in the business rules and how people talk but a simplification of it is captured in code. Certain naming is consistent and the necessary invariants are enforced in the model.
A bounded context is mostly conceptual (might be a namespace, module, project in code as well...). It is the intention to keep a domain model consistent within it. So within the context, a certain ubiquitous language is used. And a model need only serve the needs of THAT context. It is the boundary in which the model can be used. In terms of recognizing these relationships? Some might be subtle but most are not. At least some people in the team will want to "avoid duplication" by unifying the model... so that is a clear indication that there is a relationship. Names are often the same or similar... or could be the same but one is better suited to one domain and another to another domain.
A context map is a bit more of a project management tool. It is a map of how different contexts (and the models within) relate to each other. In an Ordering Domain in an e-commerce system you may have a product. It would lead to A LOT of complication trying to have a unified Product in a model that spanned Ordering, Payments, Content for the website and Inventory domains (for example). So each of those domains should have a separate model. The context map is a diagram and related documentation that relates these bounded contexts together since there would be relationships and translation of data across from one model to the next, as an order flows through the system.
The last element you asked about is a subdomain. Here you probably are referring to a generic subdomain. Personally, I think the name is a little confusing. It makes it seem like a subset of the model. Maybe this is on purpose but I generally think of them as their own domain, just one that is not central to the business's proposition. For instance, if the aforementioned e-commerce company was known for its same day or next day delivery, then they probably shouldn't buy an off-the-shelf solution to inventory and shipping management. On the other hand, if they were focusing on a market that just wanted the cheapest deal but didn't mind waiting a few days, then that would be a perfect candidate for a generic subdomain.
My DDD glossary which has plenty of links at the bottom to more detailed articles.
If you are serious about learning this subject and can get your hands on some books:
Domain-driven Design by Eric Evans
Implementing Domain-driven Design by Vaughn Vernon
Domain-driven Design made functional by Scott Wlaschin (my favourite)
I've started learning the principles of DDD and I'm currently trying to get a grasp of the concept of a bounded context. In particular, how do you decide just how big (or small) it has to be? Yeah, I know, as small as possible and as big as necessary (according to Vaughn Vernon).
Let's say I were to model a blog. I could then go and say there are 3 bounded contexts involved: 1) Front Page (featuring the most recent articles, no comments shown) 2) Discussion (a single article including comments) 3) Article Composer (where I compose an article).
However, this doesn't feel right (the ubiquitous language is the same for all of them), it seems as if I'm coming from a front end point of view and am still thinking in terms of view models or something.
Could anyone please point me in the right direction?
A blog is not a good example for use of multiple bounded context. It's not really a "big enough" software example to warrant their definitions. DDD & BC's are really aimed at big/complex enterprising software systems.
Like you say, the aggregates always have the same meaning in your 3 examples.
I gave this example of Bounded Context in a previous answer, which I hope explains BC's and when to use them: Bounded Contexts and Aggregate Roots
Try to look at your whole domain from different perspectives, as an editor of article, you probably will use sentences like creating a draft of an article, publishing an article, as an article a reader you will in example read article and comment on it. Alongside building your domain language you will identify entities and their behaviour, some of them will appear only in one perspective, some will appear in both, but you will distinct them by their behaviour. Your domain language shows you the boundries of each perspective, that you implement as a bounded contexts.
The best example I read by subdomains so far is the following.
Just examine the actual company! Each department taking part in the business process can have its own subdomain. In an ideal world each subdomain has its own bounded context in your implementation. You should ask yourself whether the company needs a new department to do this? Is it really that big?
The BC must be big enough to describe a department of a company. A typical example is a webshop, where you have a shopping core domain and invoicing, delivery and storage subdomains. Having multi-tenancy and so multiple aspects - as a previous answer described - is not enough. A blog with an author and a few readers does not require multiple departments, so you can solve this with a single bounded context. You can have multiple modules in your bounded context if you think you have medium size structures in your bounded context.
We are attempting to use DDD techniques on my current project and have started going through the process of domain modeling and are experience a lot of friction around "how to" create the Domain Model. I haven't found a lot of examples our guidance on this topic.
We have started by attempting to define the Ubiquitous Language by talking to the business users and coming up with a list of domain entities and their attributes. That's going pretty well but we are having problems with things like:
Behaviors, actions
Permissions
Business Logic (if attributeA = true then foo else bar)
I have a lot of ideas on how we could capture all of these various things (sequence diagrams, uses cases, flow charts, ect...) but if there was a formal process or some resources providing example driven guidance it'd definitely speed things up a good bit.
This is a great question.
One of the first steps I always take is to have a meeting with one (yes one) domain expert and have an open discussion about the problem domain from their perspective. I bring plenty of post-it notes and make sure I have plenty of whiteboard space. As the expert speaks I try to draw a flow or BPMN diagram on the wall using the post-its. I find it's very important to give the domain expert something visual to look at - something which he/she can physically point at and say "no, that's wrong!" (which they usually do, many times).
During these conversations I am listening closely to what the expert is saying and asking for clarification where there is ambiguity. I always find that it's better to let the ubiquitous language emerge naturally this way - rather than trying to forcefully establish it (I would never ask a domain expert to give me a list of terms).
I try to express the flow diagram in terms of commands and events - even if I do not end up using CQRS I find this naturally flows into more concrete requirements. When the flow diagram is complete (I can usually tell this because the the expert looks very pleased with it - there's a good chance he/she has never seen the domain mapped out this way and they are often thrilled by the novelty), I start to trace individual routes through the flow diagram. Often these individual routes can be easily expressed as behavioural specifications in terms of Given, When, Then style requirements. (see BDD section 3)
Once you have a collection of Given, When, Thens which cover every route through the flow diagram, you have sufficient specification to start the design phase of a domain model in exactly one Bounded Context.
I repeat the process with other domain experts. With subsequent experts I also listen for correlation between the language and terms they use. Most times different domain experts will share terms in the ubiquitous language, but will mean slightly different things. This is a sign that we are dealing with distinct bounded contexts.
My understanding of BDD is that one describes a system in user stories and then developers take those user stories and turn them into an application with the intention of adding real business value with every 'sprint' (period of software development). The result (as far as I can tell) is that the domain model emerges from the user stories throughout the development process. That is, after the first 'sprint' much of the domain model will not have been designed.
My understanding of DDD is that software development continues with reference to a full domain model, albeit an evolving one. In DDD the model is expected to change, but it is nonetheless 'complete' at all times.
This seems to be a fundamental difference between the two approaches. How have people handled this?
BDD done well does not produce a "complete" model. There's a reason that Dan North, the guy who came up with BDD, calls his blog "embracing uncertainty".
I find it useful these days to think of three kinds of things that we can analyze: the known, the knowable and the unknowable.
Known stuff is simple - for instance, logging in. It's well understood. We don't need to talk through the scenarios.
Knowable stuff is usually related to the domain, or to something that has been done before. This is a great place to do BDD, because it helps transfer knowledge - including the domain model - from the business to the developers. Talking through scenarios is a great way to understand stories better. It can also help us to find scenarios we've missed. Chris Matts, who's the analyst who helped put the "Given" in "Given, When, Then" calls this "breaking the model". He actually offered prizes for anyone who could come up with a scenario that wasn't covered in his model, which he uses scenarios to define and refine.
There's also the unknowable stuff. This happens whenever we're working on something new, or something we've never done before, or something in which nobody has expertise. You can tell if you're in this place because business people will start reacting with surprise when you come up with the scenarios they haven't thought of. BDD is a really great way of finding these places, but at this point you probably want to stop trying to nail down the scenarios and just try something out and get feedback instead. Your domain model, and your user stories, and your scenarios, will all gradually emerge (see the complex domain in the Cynefin model).
I know a lot of teams use BDD as a way of apparently eliminating this uncertainty. You can't eliminate it. You can only hide it until later, when the feedback from delivery comes back to bite you.
With respect to DDD, when we do it with BDD we tend to focus on those parts of the domain model that are relevant to the scenarios we're working on, though we might have an idea of the larger domain model overall. If you're using Feature Injection together with BDD you'll already have talked through most of the capabilities of the system, especially the new ones, so you'll have an idea of what kind of things are in the domain. Evolution and all other rules still apply. BDD and DDD work really, really well together, with conversations around scenarios helping to bring out the domain language. They are not fundamentally different, but completely supportive and compatible.
Please also read the answer I gave to this similar question, which features a video of Dan North and myself talking about this very topic.
I would include user stories, DDD and BDD as they are very very dependent of each other. I tried to summarise the link here: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/
I hope this picture is both simple and rich enough to explain the link between these "concepts"
I am on a tight schedule with my project so don't have time to read books to understand it.
Just like anything else we can put it in few lines after reading books for few times. So here i need some description about each terms in DDD practices guideline so I can apply them bit at a piece to my project.
I already know terms in general but can't put it in terms with C# Project.
Below are the terms i have so far known out of reading some brief description in relation with C# project. Like What is the purpose of it in C# project.
Services
Factories
Repository
Aggregates
DomainObjects
Infrastructure
I am really confused about Infrastructure, Repository and Services
When to use Services and when to use Repository?
Please let me know if anyway i can make this question more clear
I recommend that you read through the Domain-Driven Design Quickly book from infoq, it is short, free in pdf form that you can download right away and does its' best to summarize the concepts presented in Eric Evan's Blue Bible
You didn't specify which language/framework the project you are currently working on is in, if it is a .NET project then take a look at the source code for CodeCampServer for a good example.
There is also a fairly more complicated example named Fohjin.DDD that you can look at (it has a focus on CQRS concepts that may be more than you are looking for)
Steve Bohlen has also given a presentation to an alt.net crowd on DDD, you can find the videos from links off of his blog post
I've just posted a blog post which lists these and some other resources as well.
Hopefully some of these resources will help you get started quickly.
This is my understanding and I did NOT read any DDD book, even the holy bible of it.
Services - stateless classes that usually operate on different layer objects, thus helping to decouple them; also to avoid code duplication
Factories - classes that knows how to create objects, thus decouple invoking code from knowing implementation details, making it easier to switch implementations; many factories also help to auto-resolve object dependencies (IoC containers); factories are infrastructure
Repository - interfaces (and corresponding implementations) that narrows data access to the bare minimum that clients should know about
Aggregates - classes that unifies access to several related entities via single interfaces (e.g. order and line items)
Domain Objects - classes that operate purely on domain/business logic, and do not care about persistence, presentation, or other concerns
Infrastructure - classes/layers that glue different objects or layers together; contains the actual implementation details that are not important to real application/user at all (e.g. how data is written to database, how HTTP form is mapped to view models).
Repository provides access to a very specific, usually single, kind of domain object. They emulate collection of objects, to some extent. Services usually operate on very different types of objects, usually accessed via static methods (do not have state), and can perform any operation (e.g. send email, prepare report), while repositories concentrate on CRUD methods.
DDD what all terms mean for Joe the plumber who can’t afford to read books few times?
I would say - not much. Not enough for sure.
I think you're being quite ambitious in trying to apply a new technique to a project that's under such tight deadlines that you can't take the time to study the technique in detail.
At a high level DDD is about decomposing your solution into layers and allocating responsibilities cleanly. If you attempt just to do that in your application you're likely to get some benefit. Later, when you have more time to study, you may discover that you didn't quite follow all the details of the DDD approach - I don't see that as a problem, you proabably already got some benefit of thoughtful structure even if you deviated from some of the DDD guidance.
To specifically answer your question in detail would just mean reiterating material that's already out there: Seems to me that this document nicely summarises the terms you're asking about.
They say about Services:
Some concepts from the domain aren’t
natural to model as objects. Forcing
the required domain functionality to
be the responsibility of an ENTITY or
VALUE either distorts the definition
of a model-based object or adds
meaningless artificial objects.
Therefore: When a significant process
or transformation in the domain is not
a natural responsibility of an ENTITY
or VALUE OBJECT, add an operation to
the model as a standalone interface
declared as a SERVICE.
Now the thing about this kind of wisdom is that to apply it you need to be able to spot when you are "distorting the definition". And I suspect that only with experience (or guidance from someone who is experienced) do you gain the insight to spot such things.
You must expect to experiment with ideas, get it a bit wrong sometimes, then reflect on why your decisions hurt or work. Your goal should not be to do DDD for its own sake, but to produce good software. When you find it cumbersome to implement something, or difficult to maintain something think about why this is, then examine what you did in the light of DDD advice. At that point you may say "Oh, if I had made that a Service, the Model would be so nmuch cleaner", or whatever.
You may find it helpful to read an example.: