In previous chapter we precisely discussed what domain is and how to solve complex domain issues. Now when we know that domain is partial and can be described in various ubiquitous language words that can be aligned to some line by their common meaning. However we still don't know how to solve questions that domain ask. We can try to apply any software design to already crafted ubiquitous language however we will not succeed. The reasons why it will be so are discussed in this chapter. In this chapter we will cover following questions:
- how UL terminology can have different meanings in different domain parts;
- what is Bounded Context;
- what is the relation between Domain Model and Bounded Context;
- how to name your Bounded Contexts;
- SOA and Bounded Contexts;
- using several Bounded Contexts on same domain part.
There are a lot of terms in our ubiquitous language, some of them can appear in several parts of our domain. Is this a correct situation or we did anything wrong, since we said that ubiquitous language is unique for specific domain part? Indeed, recalling our e-commerce example we can remember that domain expert said that we should talk with other domain experts who are working on invoicing part of the project and one who manages products in stock part. When talking to them we understood that there is an order which exists on both subdomains in purchasing part of our domain and in invoicing part of our domain. After talking with domain experts that works in inventory and shipping area we also understood that there is a product that exists in purchasing, inventory and shipping domain parts. How can we separate this and align our domain parts according ubiquitous language so they will not contain same words? Well, the simple answer is that we can't do it. So how we should model this situation? Maybe we missed anything? Lets once again talk to domain experts however now lets ask them what in their domain all this words means? We should not stick to only words, but we should also stick to their meaning in various domain parts.
Below is our talk with domain expert from purchasing part of our domain about what is order and product in their area.
DE - domain expert DV - developer
DE: Hi, nice to see you once again DV: Yes, thank you. We faced with some not clarified things and we would like to make them clear with your help DE: Sure, what is it? DV: Can you explain to us what is order and product in your domain area in particular? DE: It's simple, as was said order can contain several products that customer want to purchase. Order can contains several products however total amount should not be more then 100 000 USD. Products with which we usually work contains only price, since we are not interested in other things. We also are responsible for processing coupons, they can be added to order if its amount is more than 5000 USD. DV: Ok, thank you
After this talk with had a conversation with domain experts from invoicing domain part.
DV: So can you describe what is order? DE: It's easy, product contains total amount of purchased products and it also contains list of invoices that are related with it. When we process invoices we also check that they are not bigger than total amount of whole purchased products and so on. There are several checks, like that we don't allow to process invoices if there is one that is not yet paid. DV: Customer can pay online or offline in company office? DE: Yes, for the offline invoices we also keep tracking in which office its invoices were paid. For online invoices we use special payment gateways, that allows us to process cards. DV: So it is only order,invoice and payments here? DE: Yes DV: Thank you
We had two conversations, however there are two more to go. Once we did all hard work with understanding what order means in different domain parts, lets see what product is. Lets talk to the domain expert who manages all products lifecycle - the products in stock management or inventory as it is said in e-commerce.
DV: Can you please explain what product means in terms of your domain area? DE: Of course, well we can have a lot of products, they are split in categories and sub-categories. Each of them can have various attributes like price, color, length, width, height. We also have a big number of specific per category product attributes, so products can be easy filtered. And we also provide brief description to each product and several of images of it. DV: That was quite a lot of important information here for me. Thank you DE: Sure
After this talk we only need to have a conversation with domain experts responsible for orders shipping.
DV: Hi, we would like to ask what the meaning of order and products is in your domain area? DE: No problem, we are responsible for making shipping successful. We should consider if our order contains fragile or other product types that should be carefully packed. If order products have big height, width or length we can split order shipping in several shipping items that will be shipped independent each from other. So for us order is basically contains several products in which we are interested. We also can track each of shipping items for order. DV: Thank you, that was really helpful
So after we talked to each of the domain expert working in their specific domain area what we can conclude from it? Well, lets see:
- the domain expert in purchasing part of our domain understands order as a set of products. They also said that they have restrictions about order total amount. Order can have a coupon to be applied, but the amount of order should not be less then 5000 USD. As we were told early they deal with orders that can have not all information provided by customer. As for products they are only interested in their price and nothing more;
- the domain expert from invoicing part of our domain said that he is only interested in order as a set of total amount to be paid for products and as a set of invoices that should be paid. He also said that there are several constraints in his area, and other things to consider like payments sessions, offices where offline payment was made;
- the domain expert from inventory part of our domain said that he is interested in product as a big set of various attributes, that allows customers to filter and find the one they need. Such attributes can include price, color, product specific attributes, description and product images;
- the domain expert from shipping part of our domain said that he is only interested in order as a set of products to be shipped. each product can have various attributes that should be carefully considered when shipping order. He also said that they can track order and split it in several shipping items, each containing several products from order depending on their attributes.
So as we can see, domain experts from different domain parts have same words as order and product, but meaning of this words is different. Meaning of them depends on the context in which we are talking about them. This is an important thing to understand ubiquitous language words and language by its own does not exist outside any context, because meaning of ubiquitous language words is extremely important. If this words still exists in different domain parts how can we model them out? We will see it in next chapters that contains Tactical part of DDD.
For now lets reconsider what we know:
- domain parts contains ubiquitous language words;
- domain parts can be crafted from ubiquitous language aligned by common meaning;
- context in which we speak about ubiquitous language words is extremely important.
By knowing this we already can understand one of the vital part of the Strategic DDD - Bounded Context. Bounded Context - a set of ubiquitous language words that have an unique and one meaning in the context borders. Thus, we can say that there can exist several bounded context in our domain model. Each context can be bound to the particular part of our domain as we saw above. This is the relation between domain parts, such as core domain, subdomain and the bounded context. Early we said that domain parts and domain by itself can be called as a problem space, since it contains various questions and issues to be solved. The bounded context contains particular and well crafted meaning of each word from ubiquitous language they are unified to context meaning. In this way we can answer the questions that domain asks. So bounded context is a part of domain model which is solution space.
Once we know what is bounded context and how to determine it - area where words from ubiquitous language have only one meaning, how should we name it? Usually you will name your bounded context in one or two words, that highlights meaning of this context.
Recalling our e-commerce example, lets see how we should name our bounded contexts and why:
- Inventory is a good name for bounded context since it highlight what this bounded context means. It is a set of items that can be picked up by various attributes and filters. However Products is not a good name for bounded context, since it does not contain any meaning of what is this bounded context and what it contains;
- Purchasing is a good name for bounded context. It highlights that we buy products and making order in checkout process from cart. However Orders is not a good name, since it does not contain any context;
- Account - contains context, that can include registering, managing account information and so on. However Users is not a good name, since it is anemic and does not tell anything about context.
As we described in previous chapter you also can try to name your bounded context in the same manner as domain parts, that is - name them as a anything similar to the department where your domain experts are working.
In complex projects when bounded contexts are set up correctly you can easy move to SOA architecture. Indeed, if every bounded context has its own meaning and does not share anything with other contexts in can be safely made as service, to which other bounded contexts, possibly made as services too, will be contacting. Various teams can be working on SOA services and be independent each from other changes in some way. It allows to concentrate developers on particular area and minimize risks of failing something in other part of your domain, since it is split correctly in parts. However SOA does not mean that your bounded contexts will live on their own. No, they will communicate with other bounded context through translation layer. The teams communication also will be needed for this of course.
As we said each bounded context should be bound to some part of our domain - core domain or subdomain. Can it possible to bound two or more contexts to the same domain part? Yes, such situations can exist, but they usually are signals that you did not crafted your ubiquitous language well, and did not separated your domain parts as needed. What consequences such approach - two or more contexts on one domain part, can bring to us? Lets see:
- we cant separate correctly domain parts, so risks of breaking anything in other domain part increase;
- such bounded contexts will require a lot of teams communication, that can take too much time;
- from the software part it can result in big code duplication;
- since bounded contexts are imposed on each other, we can see a situation when two teams can try to model same thing but in different ubiquitous language words.
So to avoid all this consequences, we should not try to apply several bounded contexts to one domain area. If not doing so then how we can solve this situation? As was said, it can be a result of not well crafted ubiquitous language, so we should reconsider what we have in ubiquitous language and what words meaning is. We should try to split this domain part into several parts. It can be that we tried to combine various domain parts in one, and this resulted in such situation.
Lets summarize what we have learned from this chapter:
- we learned what is the Bounded Context;
- we learned of how same UL word can have different meaning in different Bounded Contexts;
- we learned that Bounded Context is a solution space;
- we learned how to name Bounded Contexts;
- we learned how Bounded Contexts and SOA architecture are related;
- we learned why we should not try to apply several Bounded Contexts.
What is next?
So far we learned what Bounded Context is. We said that Bounded Context don't live on their own and that they communicate with other Bounded Contexts. In next chapter we will see how Bounded Contexts can communicate and what types of such communications there are in DDD.