This article introduces Domain-Driven Design (DDD) through the practical lenses of subdomains discovery and bounded context definition. Using InPost as a real-world example, it shows how understanding the business domain, visualizing value creation, and defining a Ubiquitous Language help teams break complex systems into clear, meaningful boundaries.
Domain-Driven Design (DDD) is an approach to software development that focuses on understanding the business domain deeply and using that knowledge to guide how the software is designed. In short DDD helps developers build better software by first understanding the business problems and rules before writing code.
A domain is the real-world business area or problem space that a software system is built to support, such as e-commerce, banking, or healthcare.
A bounded context is a clear boundary within which a specific domain model and its language have a consistent meaning. Inside a bounded context, terms and rules are well defined, but the same terms may mean something different in another bounded context.
Although the terms are related, Domain and Bounded Context are not the same thing. What is a Bounded Context ? It describes how part of the domain is modeled. It exists inside the software. It is precise and technical. A single domain can contain multiple bounded contexts.
Why Are Domains Not Enough ? If we only define a domain: Business concepts remain too broad, different teams may interpret terms differently. The model becomes confusing and inconsistent.
How does DDD translate into software development ? So we have domains which represent the overall business problem, after we have subdomains which represent smaller areas inside the domain and then we have bounded contexts which are precise modeling boundaries inside subdomains.
Example:
A bounded context is a business-driven boundary (not a microservice), and a microservice is a technical implementation that can be used to implement that boundary.
Image source here
We analyze the domain by listening, modeling, and observing how the business works. Subdomains emerge when we notice different responsibilities, rules, and goals.
Based on my own experience, usage of simple Unified Modeling Language (UML) diagrams work best when exploring the domain but remember those diagrams are not used to fully specify the domain model. Eric Evans is very clear about this point. UML and diagrams are tools for thinking and discussion, not design deliverables that must be complete or perfect.
What does UML help us achieve ? UML helps people visualize ideas. It supports collaborative thinking. It keeps everyone focused on the same concepts. UML diagrams anchor conversations and help people share a mental model. UML is not about correctness, it is about shared understanding.
UML is particularly good at showing: relationships between domain concepts, associations and dependencies, ownership and boundaries.
In Domain-Driven Design, UML helps us understand and communicate the model, but the real model lives in the code.
This article doesn’t aim to give you a comprehensive understanding of what UML is but there are many good materials and tools available online like geeksforgeeks and drawio (drawio is available in desktop version).
I would like to explain to you how to use simplified structural UML diagrams together with Ubiquitous Language (concept created by Eric Evans in his book Domain-Driven Design)
Ubiquitous Language is a shared language used by both domain experts and developers to describe the domain consistently, and it is used everywhere: in conversations, documents, diagrams, tests, and code. You can imagine that is the registry of the most important key terms that exist in the business domain. If developers and business experts cannot speak clearly to each other, the software will never be clear either.
If you would like to get information about Domain-Driven Design first hand I highly recommend reading “Domain-Driven Design” by Eric Evans.
Now let’s practise the terms which we just learned about.
In our article for the purpose of domain analysis we will use a company called InPost. InPost is a logistics and delivery company headquartered in Poland. It operates a large network of parcel lockers, offers courier delivery services, and provides e-commerce logistics solutions both domestically and internationally.
In domain-driven design terms, we can describe InPost’s primary domain as logistic or delivery domain. This domain focuses on reliably moving parcels and shipments from senders to recipients using both physical infrastructure (lockers, courier networks) and digital services (mobile app, tracking and integration for online shops).
But remember that any domain analysis of business must be validated by business experts to confirm its correctness. In Domain-Driven Design, the source of truth is: Domain experts, Business stakeholders, People who operate the system daily. Even a very good external analysis is still an assumption. Without business validation, models are educated guesses.
Below you will see a value chain proposed by me to cover how InPost creates value step by step. What is the value chain and why did I propose it ? Value Chain is a way to visualize how a business creates value step by step, from the first customer request to the final delivered outcome. It shows which activities directly create value for the customer and which activities support or enable that value. In Domain-Driven Design, the value chain helps us identify important subdomains and discover what parts of the business are core, supporting, or generic.
Eric Evans encourages using business perspectives and avoiding purely technical decomposition. While he doesn’t prescribe “value chain” as a named technique, the distillation process and core domain identification strongly align with value-chain thinking.
Miro diagram here
In the above diagram Billing appears late in the value chain because it represents capturing value after delivery, not because it happens last in time.
A value chain that represents a business is not a recipe for full domain analysis, but it may help and support you during that process. It may happen that some steps from the value chain will be perfect to become a subdomains in DDD. For example Parcel Induction could become a core subdomain (the one giving competitive advantage to InPost) because it will cover usage of InPost Locker, although Locker Management itself is a subdomain which I think is rather used by Parcel Induction and Parcel Pickup steps in presented value chain.
Now let’s define some terms with Ubiquitous Language.
Orders Management plan and manage what should be delivered (business intent). Core terms we can identify are:
Locker Management manages physical parcel acceptance and locker operations. Core terms we can identify are:
Based on above definition I generated bellow diagrams with Miro AI feature
Miro diagram here
Miro diagram here
Now above you see valid structural UML diagrams but normally I am focusing only on names and relationships, imagine that somebody from business is looking at that ? They will not understand the column types and constraints, they will not understand the relationship symbols. Remember what we said at the beginning, UML is not about correctness, it is about shared understanding.
Below you see a simplified version of the UML diagram that gives us some insights about the domain. And that’s what I recommend to you as a starting point because we don’t define a database schema, our only focus is the terminology and relationships between terms.
Miro diagram here
Key takeaways from the last diagram ?:
This diagram shows a clear separation between planning delivery (Order Management) and executing delivery (Locker Management). It reveals how physical reality starts only when a parcel is accepted, how pricing may depend on other business domains, and how bounded contexts communicate through events rather than shared objects.
All of these elements we discussed: domain understanding, subdomains, value chain analysis, ubiquitous language, and UML modeling, come together to help us define Bounded Contexts. A bounded context is a business-driven boundary within which a model and its language are consistent.
In our InPost example, Order Management and Locker Management naturally emerge as separate bounded contexts because they have different responsibilities, rules, and meanings. These bounded contexts can then be implemented as independent modules or microservices, depending on architectural needs. (Order Management is a subdomain because it represents a business responsibility. It is also a bounded context because we chose to model that responsibility as a separate, consistent software boundary.)
At this point, we are ready to move from analysis to development. Each bounded context can be owned by a team, implemented independently, and evolved safely. Integration between contexts should happen through well-defined contracts and events, not shared databases or shared models. This is how DDD helps prevent tightly coupled systems and supports scalable architectures such as microservices.
The most important takeaway is that DDD is not about drawing diagrams or choosing microservices upfront. It is about deeply understanding the business, collaborating with domain experts, and letting that understanding guide software design. When done well, Domain-Driven Design creates systems that are easier to understand, easier to change, and far better aligned with real business needs.
Sources:
