People who are new to DDD constantly ask questions similiar to "what is domain?", "how to determine the domain?" and "what is model?". The answer can be simple or not, depending on your level of understanding what your project is about.
The simple answer is that domain is a problem project solves. In the process of implementing a project you have to ask questions about the problem.
For an e-commerce project the domain is Sales. It may include various features like making orders, delivery, invoices and so on.
For a project that aims to automate freight domain is Shipping.
DDD is a not that easy to master so let's quote Wikipedia a bit:
A sphere of knowledge (ontology), influence, or activity. The subject area to which the user applies a program is the domain of the software
In the Domain Driven Design any user stories also known as use cases should be modeled and implemented in terms of domain.
All these aspects and abstractions constitute a Model. So domain is our whole problem space, the business we're going to automate.
And domain model is our solution, the vision of domain in terms of code. So DDD is the process of moving things from problem space
to solution space. I know it sounds pretty tricky but you'll get used to it.
###Structure of DDD
The Domain Driven Design is mainly separated in two parts:
- Strategic;
- Tactical;
The strategic design is about global view of your domain model and includes the following:
- Ubiquitous Language;
- Domain Model (and their types);
- Bounded Contexts;
- Context Maps.
The tactical design is about implementation of particular bounded context mapped on needed domain model part. The tactical design includes the following:
- Entities;
- Value Objects;
- Specifications;
- Repositories;
- Factories;
- Services;
We will look at this two parts of DDD in the next chapters. For now you should note that without correctly applied strategic design you will not get any benefit from your Domain, since you will miss the key features of DDD that are included in its strategic part.
###Applying DDD
You may already be very interested and eagerly waiting to apply DDD to the project you are currently working on, or will be working on very soon. However lets see the use cases of where and when the Domain Driven Design should be applied, and when it should be avoided. You should apply DDD in following cases:
- your project will be big and can include a set of service, that by their own can be huge;
- your current project gets bigger and you loosing control on it;
- you have enough time and money for DDD;
- you have a customer who is interested in building good software that reflects his domain and specifications;
- you have at least few people who are not new for DDD or already was applying it to other projects in some way;
- your project has complex domain and not a simple big set of CRUD operations;
- ther project you are working on or will be working is a mature or long running project.
The above are reasons when you should apply DDD, so lets see what benefits you are getting from it:
- allows you to control and maintain your project easily, by separating it in several domain models that can be crafted by independent teams;
- allows you to create software modeled in needs and terms of customer without any specification or needs mismatch;
- your developers has clear understanding on what things and why they are working on;
- you don't bother yourself with creating vague and synthetic modeled software, you just put the language that your customer speaks to the code.
This are pretty big pluses, especially for those of you who can remember when you was writing code according needed specifications as you though so,
however it was discovered later that your code missed various customer needs. How does DDD allows and helps you to do such things,
what tools does it brings to you? How you should model your Domain and craft your Domain Models? The answer is simple - you should listen
to the language that your customer speak and craft words from it wisely. In terms of DDD the common language that you and your customer speak is called
ubiquitous language. However we already touched very interesting DDD parts, so lets start for now and see whole picture.
TBD
In next chapter we will closely see what is a Strategic part of DDD, from what parts it consists and what each of them about.
TBD