Strategic DDD

Bound Context

Bound Context represents a meaning of the word within a different context. For example phrase “Bank” can have several meanings. In the context of “Finance”, it might mean “A financial institution that provides various services such as deposits, loans, and investments”. On the other within the “River Geography” context, “Bank” has different meaning that “The sides of a river or body of water (‘zandbank’ in dutch)”.

“To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.” -- Eric Evans

Before Domain Driven Design one of the common approaches was trying to define a model that represented complete domain. The problem in large domains is that it is difficult to correctly interpret words and meanings. When modeling our bounded context, it is of high importance to avoid ambiguity, meaning that words can have the same meaning.

“It is not the domain expert's knowledge that goes to production, it is the assumption of the developers that goes to production” -- Alberto Brandolini

This is why identifying bound contexts makes sense.

For our example, we could have two contexts:

River Geography context – riverbank Financial context – financial institution for various services.

For example, we might want to build a feature which introduces monitoring so we can track ‘banks’. If we are not clear on the context. Maybe we want to monitor the thickness of the riverbanks to track the condition of our waterways, or we want to monitor the financial wellbeing of financial banks.

Ubiquitous Language

We already mentioned that bound context is critical, because it gives us precise vocabulary. This precise vocabulary is commonly called ubiquitous language. We can say that Ubiquitous Language is how people communicate in a specific group.

It is how people use language in that domain. We want to use this vocabulary when we build software, to keep it consistent. For example, we might say “User” while some other team says “Customer”. Furthermore, part of the team might use the term “Property” while other parts of the company might say “Instruction” for the very same thing.

Generally speaking, ubiquitous language should be consistently used throughout design process, task definitions, development, project documentation and code. If we are calling consumers of our application “Customers” we should use this both in documentation as well as variable names in our code.

If we want to understand domain driven design, it is important to understand the definitions and the vocabulary.

Domain and Domain logic

Commonly referred to as a business logic. Basically, this is a set of rules that define creation, processing and storage of your data. More importantly, business logic explains not only how but also why is the processing important in the exact way your business does it.

The domain is what our products is all about. This is what we sales is selling, what developers are developing, what product managers aim to improve and make better, what marketing is promoting. Generally, the domain is a playground within which company is creating a new value.

Domain represents knowledge, ideas, metrics, goals, data, reports, everything that contributes to the problem one company is trying to solve.

Finally, domain logic represents all the rules that helps companies to deal with complex business logic and to provide value to their customers.

Subdomain

Large domains can be represented as sets of subdomains. Each subdomain refers to different part of the business logic. For example, if we look at the ecommerce web site we might recognize different subdomains. There would be account management; supply chain management; orders and invoices; refund management etc.

This is just one example of subdomains, different projects and teams might have different priorities and segmentation.

Domain experts

Domain experts are people who will use our software and have experience in that area. They are people with relevant experience. This experience is important for software developers because they probably won’t have it.

Firstly, remember, making software is not about writing code. It is about building tools to help in doing some work. Because if we don’t know what kind of work is someone doing, we can not make a good tool.