To ask this question in the shortest way possible: can they be different?
Background: Vlad Khononov in his excellent book 'Learning Domain-Driven Design (2021)' writes (p55):
The supplier's public interface is not intended to conform to its
ubiquitous language. Instead, it is intended to expose a protocol
convenient for the consumers, expressed in an integration-oriented
language.
In a sense, the open-host service pattern is a reversal of the anticorruption layer pattern: instead of the consumer, the supplier implements
the translation of its internal model.
Whereas, Olaf Zimmerman in a great article (2021) (https://eprints.cs.univie.ac.at/6948/1/europlop21-s16-camera-ready2.pdf) writes:
But in order to make the API understandable to domain experts, it is
essential that names and abstractions in the API follow the terms
defined in the ubiqitous language which is formally specified by the
domain model.
I think the anwer to question would be YES: it's possible to use different terms in published language and ubiquitous language for the same domain element. In the domain model you register the different terminology by applying 'aliases': an alias denotes the published language term used for an element in the domain model which is named according the ubiquitous language of the corresponsing bounded context.
What do you think?
The question is how much translation do Devs (internal and external) need to do between terms in the API vs. words in UL. It is almost always a trade-off, one that is shaped over time as the product and its API evolve.
All these patterns are acceptable and effective in their way:
A consumer-friendly API that at times deviates from UL
An API that reflects UL terms in APIs, ensuring internal and external stakeholders share the same view of the bounded context
A translation layer that maps the consumer-friendly external API to the internal UL terminology through aliases
Managing an external API means less wriggle room if you uncover terminology changes. Instead of trying to retain terms as-is, Approach 3 helps you improve the internal UL while still protecting the API sanctity.
You can start with Approach 2 by default and strive to retain it, but be open to being guided by external input and switch approaches.
Ubiquitous language
Internally restricted and applied only within a specific Bounded Context. Will lose meaning in other Bounded Contexts.
Commonly used by Domain Experts, Business Analysts, Engineers, etc. to communicate with each others under Bounded Context. Therefore, mainly expressed via human language writing/speaking (eg: English).
Published language
Publicly used to communicate (aka integrate) between different Bounded Contexts. Have agreed-meaning across Bounded Contexts.
Mainly used by engineers working in different Bounded Contexts to agree on integration approach (open-host, client-server, pub-sub, etc.). Therefore, mainly expressed via technical format (API, JSON, XML, Protocol Buffer, etc.)
Related
What are the key differentials between the shared-kernel and published-language strategic patterns opted in Domain driven design (DDD)?
Both shared-kernel and published-language are part of the Context Maps patterns collection. Context Mapping is a very useful and powerful tool that allows one to see what kind of dependencies link systems together. They can also highlight teams relationships.
A shared-kernel means that 2 systems are strongly coupled by sharing a shared artifact (model, DLL, Jar, DB, ...). If those 2 systems are handled by 2 different teams, it means that whenever Team A change something, it will impact Team B and vice versa.
A published-language is a model that is well documented that everyone can understand and translate. Think of iCal, VCard or such things.
Michael Plöd did a great job on documenting Context Maps patterns, you can have a look here.
They are completely different things.
Shared kernel basically is a model shared by two bounded context.
Published language often goes together with the open host service pattern, and is a well known language, used to define the offered services. For example, JSON or XML.
Consider certain kinds of objects involved Domain-Driven Design (DDD): Entities, Value Objects, Domain Events, and Domain Services.
Which of these are considered to be Domain Objects? And are there other names for abstractions that encapsulate a subset of those?
I can identify various abstractions that are useful to have when talking about DDD or domain models:
Entities and Value Objects. I often find myself mentioning "Entities or Value Objects". Most notably, these are the ones that model the domain's state. In contrast, Domain Services are stateless, and I would argue that Domain Events merely reflect information about how the domain came to be in its current state.
Entities, Value Objects, and Domain Events. These may all contain or represent data, whereas the Domain Services only define behavior.
All objects recognized by the domain model. It is useful to be able to talk about parts of the domain model in general, as opposed to concepts outside of it.
It's interesting how even Stack Overflow's domain-object tag has a confusing definition:
Domain Objects are objects made for dealing with the domain logic at the Model layer. These objects generally simulate real (or virtual) items from real-life: Person, Post, Document, etc.
The initial definition, focused on "dealing with the domain logic", leans towards "all objects recognized by the domain model". The examples then lean towards "Entities and Value Objects".
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Which of these are considered to be Domain Objects?
All of them. They are "objects" that implement our domain model. In the original DDD text, Eric Evans also used the phrase "model elements".
The distinctions between them are largely a consequence of the constraints of the Java language. You wouldn't need "value objects" if you could just create bespoke values; you wouldn't need "domain services" if you could just pass around the capabilities you need. You wouldn't need "domain events" if you have "messaging" as a ubiquitous construct, and so on.
DDD hammers on a clearly defined, unambiguous Ubiquitous Language, and with good reason. Shouldn't it lead by example? :)
Well, part of the riddle is that these patterns are part of a general purpose language, and one of the central messages of DDD is that you shouldn't allow general purpose concerns to distract you from the domain itself.
That said... yeah - it would be better today if Evans had a rich understanding of these ideas eighteen years ago, and was able to introduce the best language and provide counter measures to prevent semantic diffusion.
Im new to learn DDD concept and i cant understand something.
1-What difference between Context Map and Bounded Context and SubDomain?
2-How to recognize relation between Bounded Context ?
As said in the comment, this is a wide subject, and very important in DDD. It is the strategic part of DDD. Anyway I will try to answer your questions with an overall explanation:
DDD is about understanding and distilling the domain of the problem we want to solve. It is a continuous process of learning about the domain, talking to the domain experts. All people (developers, business people, etc) speak the same language. This language is used everywhere (conversations, documentation, source code, ...). It is called the Ubiquitous Language (UL).
The problem domain may have different areas of functionality, which would be domains too. They are the subdomains. So a subdomain is a subset of the problem domain. It is like splitting the problem into smaller subproblems, and a subdomain would be the domain of a subproblem. There are 3 kinds of subdomains:
Core: The point of distillation is to discover the subdomain that has value for the business, i.e., the one that will make your product better than others of the same kind. Such subdomain is the "core subdomain". For example, in "project management", the "task assignement" would be core.
Supporting: It is specialized in some business aspect that helps the core functionality. For example, in "project management", a "calendar" (for marking tasks delivery dates).
Generic: Functionality that maybe needed by any kind of application. For example, authentication and authorization of users.
Subdomains belong to the problem space.
To solve the problem, you model the subdomains, and you create bounded contexts (BCs). In practice, a BC is an autonomous application that contains the software model of a subdomain. A BC has its own UL. It is the context on which a term of the UL has a meaning. UL and BCs are the most important things in DDD. UL drives the BCs identification.
Ideally, you should align 1:1 the subdomains of the problem space with the BCs of the solution space, i.e., you should have a BC for each subdomain.
A team can develop one or more BCs, but a BC should be developed by just one team.
BCs belong to the solution space.
Context Map: It is a drawing that shows the BCs, and the relationships among them. Every relationship is classified in one of the following patterns:
Partnership
Shared Kernel
Customer-Supplier
Conformist
Anticorruption Layer
Open Host Service
Published Language
Separate Ways
Big Ball of Mud
Recognizing which pattern to apply in a relationship it will depend on the particular case you have. Some things that you have to consider are:
The 2 teams collaborate together.
One of the teams doesn't care about the other one.
The teams can negotiate.
The teams are independent.
Changes on a model (upstream) affects to the other model (downstream).
As #Augusto mentioned, this is a couple of chapters in the blue book, but here goes.
The domain model is found in the business rules and how people talk but a simplification of it is captured in code. Certain naming is consistent and the necessary invariants are enforced in the model.
A bounded context is mostly conceptual (might be a namespace, module, project in code as well...). It is the intention to keep a domain model consistent within it. So within the context, a certain ubiquitous language is used. And a model need only serve the needs of THAT context. It is the boundary in which the model can be used. In terms of recognizing these relationships? Some might be subtle but most are not. At least some people in the team will want to "avoid duplication" by unifying the model... so that is a clear indication that there is a relationship. Names are often the same or similar... or could be the same but one is better suited to one domain and another to another domain.
A context map is a bit more of a project management tool. It is a map of how different contexts (and the models within) relate to each other. In an Ordering Domain in an e-commerce system you may have a product. It would lead to A LOT of complication trying to have a unified Product in a model that spanned Ordering, Payments, Content for the website and Inventory domains (for example). So each of those domains should have a separate model. The context map is a diagram and related documentation that relates these bounded contexts together since there would be relationships and translation of data across from one model to the next, as an order flows through the system.
The last element you asked about is a subdomain. Here you probably are referring to a generic subdomain. Personally, I think the name is a little confusing. It makes it seem like a subset of the model. Maybe this is on purpose but I generally think of them as their own domain, just one that is not central to the business's proposition. For instance, if the aforementioned e-commerce company was known for its same day or next day delivery, then they probably shouldn't buy an off-the-shelf solution to inventory and shipping management. On the other hand, if they were focusing on a market that just wanted the cheapest deal but didn't mind waiting a few days, then that would be a perfect candidate for a generic subdomain.
My DDD glossary which has plenty of links at the bottom to more detailed articles.
If you are serious about learning this subject and can get your hands on some books:
Domain-driven Design by Eric Evans
Implementing Domain-driven Design by Vaughn Vernon
Domain-driven Design made functional by Scott Wlaschin (my favourite)
I've read Eric Evan's book and am reading Vaughn Vernon's book now. I'm in the second chapter where he talks about subdomains and bounded context and am thoroughly confused now.
From what I was able to distill, there should be a 1:1 relationship between a BC and an SD. However, I read in other places that this isn't necessarily the case.
Can someone explain to me the relationship between a BC and SD?
A subdomain is a part of your business. There are core domains, supporting domains and generic domains. Core domains are where the money is, supporting domains support your core business, and generic domains are the ones you need, but don't care a lot about, so you would probably buy them of the shelf. For an insurance company, the core domain is insurance, a supporting domain could be client portfolio, and a generic domain could be something like timesheets.
In general a bounded context is a boundary within which the ubiquitous language is consistent. In DDD walhalla each subdomain would live in its own bounded context. In reality however, there is legacy, there are packages that try to do everything at once... which will force all kinds of awkard relationships.
I try to explain these concepts with my understanding.
In DDD, everything should be communicated under ubiquitous language so the technical team and business team can use the same terms and have same views on the problems
Domain in DDD represent real problem in business. Such as: E commerce is a domain, Payroll system is a domain
Domain is divided into many sub domains, so each sub domains focus smaller problems. Such as: E commerce has many sub domains such as: Shopping Cart, Billing, Product Catalog, Customer Information...
Each sub domain should have explicit responsibilities so it has a boundary to limit their functionalities, the boundary will help sub domain focus to do only 1 thing and do well. This boundary is considered as bounded context of the sub domain. The bounded context will define:
How many domain models needed for the sub domain?
Which properties needed in the each model?
Which functionalities needed in sub domain?
Ex: Shopping Cart sub domain needs models: Cart, Product, Customer Info... and contains functions to perform CRUD on the cart. Notes: The Product and Customer model in the Shopping Cart sub domain maybe not the same with the models in Product Catalogs and Customer Profiles sub domain, they just contain necessary properties to display on Shopping Cart.
Vaughn Vernon in his “Implementing Domain-Driven Design” book states that “the subdomains live in the problem space and the bounded contexts in the solution space”
Imagine a software that is being developed to support a dentist. A dentist has two problems: fixing patients’ teeth and making appointments for the patients. Fixing teeth is the core domain and making appointments is a supporting subdomain. In the core domain the medical staff cares about a patient’s dental history, can they handle general anesthesia or not, what their current problem is, etc. In the subdomain the staff (not necessarily medical staff) cares about a patient’s contact information, a date and a time that best suits both the doctor and the patient, the type of dental work needed, etc. Both domains need a model of a patient, but that model will depend on the bounded context we put in place to ensure the correct information and features are available when solving the problems of each domain.
read https://robertbasic.com/blog/bounded-contexts-and-subdomains/
Rereading the Booking Context from the blue book 18 times helped me finally get a handle. http://codeidol.com/csharp/domain-driven-design/Maintaining-Model-Integrity/Bounded-Context/
This article helped as well: http://gorodinski.com/blog/2013/04/29/sub-domains-and-bounded-contexts-in-domain-driven-design-ddd/
Here is my understanding, I would use the Hospital example to elaborate the concepts and deep dive into how is BC is different than Subdomain and why they can be a case where there is no 1:1 relationship between them
Example
Imagine we are making software for a Hospital, in which we have identified 3 subdomain
Health Care (Core domain, where they actually want to cure the patient)
Invoice (Supporting domain focused on invoicing)
Knowledge (Generic domain, where doctors maintain procedures on how to operate on a patient for a particular disease)
Now we know that Bounded Contexts are boundaries under which terms
have a very well-defined meaning. So let us apply those in Subdomains
Let's consider the term. Patient. What are the things that you think about when hearing the term patient?
Their current symptoms
Past medical records
Allergies
How about their bill-paying credibility? Current outstanding balance? Didn't think of it? The reason is you were thinking in the core subdomain space of Health Care. The bill-paying credibility makes sense only when you shift to the Invoice subdomain.
What we understand from this is the Patient term is inside a Bounded Context, its a boundary inside a subdomain where it has a very specific meaning
The reason it said
BC is in solution/implementation/programming space and not in business
space
is because here we decide what fields and behaviors should be part of the Patient model
In the core domain space, you might represent Patient it like this
class Patient {
List<Allergy> alergies;
List<MedicalRecord> records;
Age age;
boolean isAllergicTo(Allergy allergy)
boolean canTakeLocalAnesthesia()
}
Whereas in the Invoicing subdomain you might want to represent it like this
class Patient {
CreditCard creditCard;
CreditScore creditScore;
Bill currentBill;
void charge(Amount amount)
}
Similarly, the term Cure in the Health Core subdomain, would have the operations that were/are_to_be performed on a patient to cure the disease whereas in the Knowledge subdomain it would contain information about Symptoms, Diagnosis tests, Prescription suggestions, that go along with a disease.
You can now see the Health Care subdomain has multiple BCs and under a BC each term has a very specific meaning thus supporting the Ubiquitous Language
Please check this link it will help you,
Bounded Context or Context?
The term Context is a general description of a grouping of concepts, the term Bounded Context is more specific – a Bounded Context is an area of your application which has explicitly defined borders, has its own Model, and maintains its own code. Within the Bounded Context everything should be strictly consistent.
Usually, we can use the terms Context and Bounded Context interchangeably, though I tend to talk in terms of Context about the business side of things, and the term Bounded Context about the technical implementation.
In a very short and simple sentence, we can say: subdomains are part of the problem space and are chosen by The Business whereas bounded contexts are software boundaries defined by engineers.
First. The official definitions from the Blue Book is:
Domain: A sphere of knowledge, influence, or activity.
Bounded context: The delimited applicability of a particular model. Bounded contexts gives team members a clear and shared
understanding of what has to be consistent and what can develop
independently.
Note that those concepts exists by themselves before any architecture design or line of code is written down.
DDD is about having a domain model shared by business people and programmers that is reflected in source code. But with medium or bigger organisations it is not practical to have a single model. It is better to divide and conquer because:
Different areas have different needs, cultures, jargon, etc. Sometimes the same concept has different terms or viceversa.
Creating a big meeting to make people agree is costly and it is really hard to agree in something at this scale for so many people.
The cognitive load of developing an enterprise-wide mega application. Better to implement a components that can assigned to smaller teams.
So you reduce the domain modelling to an specific an concrete bounded contexts. This has the advantage of also reducing the complexity. But what if the same concept is used in several contexts? This leads me to the second question:
There should be a 1:1 relationship between a BC and an SD. However, I
read in other places that this isn't necessarily the case.
No. There is no need. Here is an example from Martin Fowler: the products and customers subdomains are shared by the sales and support bounded contexts.
Of course you try to select bounded contexts as loosely coupled as possible. But just as when you separate modules in an app there is a minimum level of coupling to make the connection. So, the same concept is modelled differently in each context (Multiple Canonical Models). This can be implemented in code by adding an Anti-Corruption-Layer that translates between models.
Moving to a single bounded context is not just a matter of software design. It would require modifying the mental model of business and this is hard. Also, people sometimes have simpler views of a domain because it reduces the complexity and their cognitive load.
Concrete example:
In this talks from DDD Europe they have an example from Amazon:
The sub-domain term Book has a very different model in different bounded contexts:
In the Catalog bounded context: Picture, title, authors, rating...
In the Shipping bounded context: Dimensions, weight, international restrictions
In the Search inside bounded context: full-text content, copyright dealing policy
So Amazon may have very complex sub-domains with lots of attributes:
Books: isbn, title, number of pages)
Clothing: size, colour, material
Computers: cpu, graphic card, hard-drive, ram
But only some of them would be relevant in different subdomains.
Let me add a diagram with a more global example
Extra resources:
"Bounded Contexts" Talk by Eric Evans in DDD Europe 2020
DDD Crew: repo resources
Virtual DDD community
Vaughn Vernon states in his book “Implementing Domain-Driven Design” the following:
"It is a desirable goal to align Subdomains one-to-one with Bounded Contexts." Page 57
A model's boundary, the bounded context, can contain ideas from various subdomains. Or a single subdomain might be represented by a number of bounded contexts. The ideal scenario would be one bounded context for one subdomain. If you are able to define multiple bounded context for a subdomain, that sometimes leans you into realizing that the subdomain is not fine-grained, and maybe the subdomain could be distilled into separated subdomains.
The other way around could also be justified, when you had multiple subdomain aspect covered in one BD, because e.g. that was pragmatic to do so.
More specifically, when the subdomain is generic, and the generic solution is easy to integrate, it may be more cost-effective to integrate it in each of the bounded contexts locally.
An example is a logging framework; it would make little sense for one of the bounded contexts to expose it as a service, as the added complexity of integrating such a solution would outweigh the benefit of not duplicating the functionality in multiple contexts.
When two different languages talking the same or similar thing, the thing is referred in 2 different contexts. You can translate the thing in 2 context in certain extents.
Similarly a term could have different meaning in different departments. in that case different context explain the term differently. Translation between two to some extent maybe possible.
Instead of saying “Bounded context” maybe try saying “bounded world”
My understanding about sub-domain and bounded context is-
Each subdomain represents a specific area of knowledge or responsibility within the overall domain, and each subdomain may have one or more responsibilities associated with it. In some cases responsibilities can split across multiple subdomains. Considering all theses issues, it can be useful to draw logical boundaries to separate those responsibilities and maintain consistency and transactional integrity.
Bounded contexts in Domain-Driven Design (DDD) are used to define these logical boundaries and provide a way to manage the complexity of large and complex systems by dividing them into smaller, more manageable parts. By using ubiquitous language we can ensure that the concepts and rules of that context are clearly understood and communicated within the development team. So we draw that boundary based on the uses language in that particular context.
So, in summary, a subdomain represents a specific area of knowledge or responsibility within the overall domain, and bounded contexts are used to manage the complexity of large systems by creating logical boundaries around specific areas of responsibility, and using a specific language, or ubiquitous language, to ensure clear communication and understanding of the concepts and rules within that context.
Bounded context ensure us that one responsibility doesn't blend with another one and finally prevent us from introducing complexity and confusion. In that sense it is very similar with SRP of SOLID
I am quite new with DDD and would like to know about any pitfalls you might want to share. I will summarize it later for more newbies to read :)
Thanks
Summary so far:
Anemic domain model where your entities are primarily only data bearing and contain no business logic
Not using bounded contexts enough
Focusing too much on patterns
There is a good presentation on this topic as well here (video).
Probably the most important one: not grokking the central, fundamental principle of the Domain Model and its representation in Ubiquitous Language. With the plethora of technology options around, it's very easy for your head to fill up with ORMs, MVC frameworks, ajax, sql vs nosql, ... So much so there's little space left for the actual problem you're trying to solve.
And that's DDD's key message: don't. Instead, explicitly focus on the problem space first and foremost. Build a domain model shorn of architectural clutter that captures, exposes and communicates the domain.
Oh, and another one: thinking you need Domain Services for everything you can do in the domain model. No. You should always first try to put domain logic with the Entity/Value type it belongs to. You should only create domain services when you find functions that don't naturally belong with an E/V. Otherwise you end up with the anaemic domain model highlighted elsewhere.
hth.
One of the biggest pitfalls is that you end up with a so-called anemic model where your entities are primarily only data bearing and contain no business logic. This situation often arises when you build your domain model on top of an existing relational data model and just make each table in the database an entity in your domain model.
You might enjoy presentation of Greg Young about why DDD fails.
In short:
Lack of intent
Anemic Domain Model
DDD-Lite
Lack of isolation
Ubiquitous what?
Lack of refinement
Proxy Domain Expert (Business analyst)
Not using bounded contexts enough. It's toward the back of the the big blue book but Eric Evans has gone on record as saying that he believes that bounded contexts and ubiquitous language are THE most important concepts.
Similarly, people tend to focus too much on the patterns. Those aren't the meat of DDD.
Also, if you do not have a lot of access to domain experts you are probably not doing DDD, at best you are DDDish.
More concretely, if you end up with many-to-many relationships, you've probably designed something wrong and need to re-evaluate your aggregate roots/contexts
Only adding to what others have already said;
My personal experience is that people often end up with an anemic model and a single model instead of multiple context specific models.
Another problem is that many focus more on the infrastructure and patterns used in DDD.
Just because you have entities and repositoriesand are using (n)Hibernate it doesn't mean you are doing DDD.
It's not from my personal experience with subject, but it was mentioned for a couple of times in DDD books and it's what I've been thinking about recently: use Entities when you really need identity, in other cases use Value Object. I.e., Entity pattern often happens to be the default choice for any model noun, and it's not the way it should be.
Beware of the Big Ball of Mud.
One of the pitfalls of domain driven design is to introduce ambiguity into a model. As explained in the article Strategic Domain Driven Design with Context Mapping:
Ambiguity is the super-villain of our
Ubiquitous Language
This may happen when two distinct concepts share the same name, or when the same concept can have different uses. It may be necessary to
expose the domain structure in
terms of bounded contexts in a context
map
If a model is used in too many different ways, or has too many responsibilities, it may be a sign that it should be divided.