In previous chapter we discussed one of the Strategic DDD part - ubiquitous language. We saw how to highlight true domain core concepts and how get them from talks with domain experts. However ubiquitous language does not exist on its own, it should be applied to some part of our domain. In this chapter we will discuss following concepts:
- what domain is?
- how to determine what types of domains do you have and their boundaries?
- what types of domains exists in DDD?
- what is a cohesive mechanism?
Your domain area can be complex, so how we can split it on several one so it can be easy for us to understand it. We already have little understanding of what domain is, however there are a lot of clarification to be done. We know that domain is usually referred as problem space, since it contains various issues to be solved and contracts to fulfill. In complex software there domain can be split in several parts. How to determine on how to do so? Does they have any boundaries?
Usually you can structure them by looking at whole picture of the ubiquitous language you crafted - some of words or key features can be aligned with same line. That means that they have something in common and belongs to the same area. Another way to determine how to split your domain is to try address questions and issues that your domain asks to solve, some of them can have various things in common that also means that they belongs to the same area.
It is easy to determine if you were doing so before. If none of this work you can always see how your domain experts workflow is organized, recalling our example with e-commerce, we can remember that the human to whom we were speaking was reproducing only one department of his company - the frontline department dealing with orders and purchase things. Domain expert said that there are other domain experts with which we can speak and clarify different things. Those are domain experts from accounting, invoicing or one that are dealing with products in stoke inventory. You can try to determine parts of your domain in this way, however you should do it very carefully. If you will determine domain parts boundaries in wrong way, this can result in UL messed up and lead to wrong modeled software. If even still it is unclear you can imagine a domain parts as a module of your software. Perhaps you already were building software that is split on modules or packages. But you still should do it carefully, domain part is not the same as it physical representation as module.
Since we said that domain is a set of issues that should be solved in correct way, we can try to make some examples. Lets consider same old e-commerce online shop. We have been spoken to domain experts, lets reconsider what questions we were asking them or maybe what is still can be unclear for us:
- who are those customers?
- from where do they come?
- is there any authentication involved?
- are they created or registered somehow, do they have any profile information?
- how order is created for them?
- is there any restrictions in order creating?
- who marks order as closed, canceled or complete?
- what happens after order is being created?
- how payment process is hold?
- any online or offline payment involved?
- what documents are need to be generated for the order if any?
- we were told about some shipping types for order, what does that mean?
- what is the role of accounting department in all this?
As you can see there are a lot of questions to ask, we can try to group them, lets start from first one. We need to understand from where our system users come from. Of course we should not do any assumptions on our own as was said, we should ask domain experts. Once we do it it should be clear for us. Well, we asked them and they said, there is another department that is responsible for work with customers. They told us that usually they ask new people for some registration information and required information. They do all the work to process this information and pass to other departments if needed. Looks like this users and information has nothing to do with customers and orders, so it can be a separated part of our domain in software. In the same manner with talks to domain experts we can try to determine boundaries of other domain parts. For purchasing department it can be that there are no users, there are customers and orders, order information, products that cost some price and so on. We also can model this as a separated part of domain. Following this way we can have talks with domain experts that do all paper work that is related to making invoices and so on. We can separate it also in other part. While doing so we should be able to see how our ubiquitous language is broken on several coupled units. So lets reconsider what the domain is:
- the domain is partial and have a lot of parts to be discovered;
- there are almost always several domain parts in your project;
- domain parts usually address coupled questions;
- ubiquitous language words can be split in several coupled by meaning units to build the picture of domain part.
We were talking that domain is partial and can have several domain parts. Indeed, as in example above we have several parts - orders and purchase issues and how to do it, online or offline payments and invoices, products in stock management, related with from where products comes from, users management flow and their registration, creating process. As was said domain and its parts are set between logically interconnected meaningful objects. So lets summarize what domain parts do we have:
- user management and registration domain part;
- ordering and purchasing management;
- invoices management;
- payments processes and management;
- orders shipping stuff;
- products in stock management.
For each of this parts there are plenty of questions and issues to be solved. How to solve them correctly? We will see it in next chapters. However this is not the end, there is more. As we said if we have several domains parts, then how to determine from which of them we should start first? Is there any instructions on how to rate one over the others? Yes, in Domain Driven Design there are different types of domain parts. They are:
- core domain;
- supporting subdomain;
- generic subdomain.
There is also one type not of domain part, but an area that can be in your domain modeled not as actual part of your domain, it is called Cohesive Mechanism. We will see what is it in this chapter. However now lets stick to those three types of domain.
Core domain - as can be understood from its name it is a vital domain part without which we cant successfully build our project. It includes all needed core concepts and contracts that should be fulfilled. We should pay as match attention as we can to this type of domain. There is usually only one core domain in your project, since all critical and vital issues should be in one place, thus team can concentrate their energy on particular domain area. Regarding our previous chapter example what would be there a core domain? Well, lets see it from the business values and domain experts talks. We know that business want to move online and make available for people to buy its products and make orders. This is important and can lead to business growth. We were asked to automate this process. What about other features of our project like payments and invoicing or users management? Lets see how each of them fits in our understanding of core domain concept. Does invoicing makes sense as a core domain? What if it is a core domain, does it fulfill our core features - making project go online and let people buy products and purchase orders? No, it is only in play when order is created and can be processed. So making it a core domain will lead us to the wrong way and we will miss the core concepts of our project. What about payments domain part and all related with it? Is it a core domain? Does it allow people to make orders online products? Indeed we can say that i helps by providing and online payments type like Visa or Mastercard, people can easily buy a product and pay for it without going anywhere. However is there a place for order in this domain part as order that contains products, maybe a cart to which user can handle its future products to buy? No, it is mainly about how payments process is handled. So this domain part also cant be named as core domain. What about our users management or shipping domain parts? Can one of them be a core domain? No, it is unlikely. The user management domain part is mainly handling how users information is processed, users accounts and so on. However as was said by domain expert there can be an anonymous orders or orders without yet correctly all information. So this does not help us match to make an order or buy it online. The shipping domain part comes into play only when order is fully paid and can be delivered to customer. Depending on the situation we can skip building this part of the software. It can be that company don't provide any shipping or only will provide not in nearest future. So as we see non of others domain parts can be named as core domain part and fulfill or core concepts and contracts that should help our business owner in his business growth by going to online. Once we discovered what is a core domain in our project we can easily put all efforts of most experienced developers on it. And let the others process less but not "not important" domain parts. It should be noted since that core domain is vital part of our project than high skilled developers that benefit from the talks with domain experts should be put to model it. If we were not doing so, then team will model software that does not reflect business specifications and have nothing in common with our domain experts expect to see. If there is one core domain, so what types are the others in our case? To make it simple lets start from Generic domain part type.
Generic subdomain - it is a type of domain part that exists in your domain, but does not reflect all or part of your domain features. Such domain parts can be easily replaced by another one implementation, without hurting the domain concepts. We also should pay attention to such domain parts but as not as much for the core domain or supporting subdomains. Considering our project, what domain part will be a good candidate for this type of domain parts? Is it an invoicing or payments domain part? No, however they can be replaced by other implementation, but they should reflect our domain contracts in one or other way. The good candidate for the generic domain part will be a users management domain part. Indeed it only contains basic information about our user in system, it does not reflect any key features of our domain. The only purpose for this domain part to exist is to make available for users to register online, provide their information so that will be easy for making orders for them, or maybe activating various coupons that can be activated only by registered users. Thus, it even can be replaced by not our but other team implementation. Such parts can be given to out-source teams instead of building in-house. The only thing we need, is to provide some basic contracts to other team, so we can later integrate their implementation in our project.
Supporting subdomain - it is a type of domain that is not core and is not generic, however it exists to provide a various domain features that can be needed by our project. Such subdomains also can be given to a third party teams, however it is better to keep this subdomains implementation in-house because they have concepts that should satisfy our core domain contracts. When given such parts to out-source we should control other team so they also should know about our domain and talk to domain experts. The other team can be not so patient in crafting domain knowledge, thus our software will be hurt. In our system there are some good candidates for such role, they are: invoicing subdomain, products in stock management subdomain and can be a payments subdomain. However depending on the situation we will want to replace our implementation of payments subdomain to one that can be bought from other teams or open-source one, it will save our time and money, of course if we can find one. The invoicing and inventory (products in stock) management domain parts cant be given simply to out-source team, since this subdomains have features that are needed by our core domain as was said. In inventory we may need different specific categories or product types that belongs to our domain or reflect it concepts. In invoicing we also can have various specific things like pre-payment or payment by installments. It can be modeled differently according our business specifications, so it is better to keep such implementation in-house and have full control over them. However for everything we need time and money, this is a downside or another side of such decision.
So far, we discussed what is the domain, that it is often referred as a problem space and what types of domain parts there can be. But what about domain parts of our project that actually don't fit in the view of domain? Such parts can be complex and related to various data processing and output. Usually it is a some sort of statistic or graphics that should be build depending on our domain data. This parts of domain does not contain any core concepts or key features, their only responsibility to process data and make calculations on them, maybe by complex algorithms. Such parts of your domain in DDD are called Cohesive mechanism. Since they does not contain any business specifications we can easily put them to out-source and dont waste our time and money on it. After it will be done by third party team we can make API for them from where they will get their data, or give them some other access to the system. If there are any complex data processing we can try to search already implemented solutions or buy other if it exists. Thus, we should isolate this part of our domain and dont waste too much time on it.
So the domain part is:
- set of coupled ubiquitous language keywords;
- have correct logic boundaries;
- can be of different type;
- a set of logically interdependent objects does not bound to any technical vision.
With that being said we will end up the review of concepts of this chapter and move on next one.
- we learned what is a domain;
- we learned how we can determine boundaries of domain parts;
- we learned that there are can be several domain parts in one project;
- we learned what types of domain parts exists and what is not a domain part;
However knowing what domains there are in your project is not enough to build system that reflects all your business specifications. We should know how this domain parts can be implemented or how they communicate with each other. What if our domain parts include same ubiquitous language words, is that we did something wrong? We will see the answers on this questions in next chapter called Bounded Contexts.
TBD