We try to split up our domain into bounded contexts with the goal to have a modular application design/architecture.
We did an enlightening EventSorming session which helped us a lot to identify bounded contexts and its aggregates. After the workshop every participant agreed on the bounded contexts we identified.
Nevertheless we feel uncomfortable as we fear our bounded contexts are still too large. EventStomring focusses on the domain events / process and that's the major building block we used to identify our bounded contexts.
We also identified aggregates like "Contract". Every contract nearly follows the same process, but the amount of data these contracts contain can differ massively. There are very simple contract types and contract types which include a lot of additional data and attachments.
Is it meaningful to declare another bounded context just because the aggregate's data is more complex?
Both approaches have their drawbacks:
Implementing all contract types in one bounded context might lead to a lot of if-Statements in the code in order to handle the differing data.
Extracting a new bounded context might lead to a lot of duplicate code just because some data differs.
Any suggestions / best practices how to handle this?
...domain events / process and that's the major building block we used
to identify our bounded contexts
BCs are not identified by processes, BCs are related to the language. Each BC has its own ubiquitous language (UL). A BC is the context in which a concept has meaning. Anyway BCs belong to the solution space. First of all you should explore the domain (problem space) and split it in subdomains, distilling the core domain. Then you model each subdomain. A BC is the context where a model lives. Ideally the relationship between subdomains and BCs is 1:1.
The process of discovering subdomains is iterative, and you will find them as you know the domain better, talking to experts. When you find a word that may have different meanings, or when two different words have the same meaning, then it means that you are crossing a boundary between BCs.
So, subdomains identification is not about processes, but about concepts and UL.
Is it meaningful to declare another bounded context just because the
aggregate's data is more complex?
No, you shouldn't create BCs arbitrary just because aggregates are complex. BCs are based on the UL.
Any suggestions / best practices how to handle this?
You should learn more about the domain (contract, types, etc) by talking to domain experts, and study your aggregate (transactional consistency)... Anyway, if you split your aggregate into anothers, it doesn't mean that they belong to different BCs, they still can belong to the same BC. A BC can have more than one aggreagate. It all depends on your concrete domain.
Bounded contexts have little to do with if-statements, so I'm not sure what you mean.
Bounded contexts are a semantically closed set of business functionalities. Basically your bounded context is well defined if it can execute its functions in complete isolation, even if the other contexts are not available.
Other than that, you can have any design inside of the context. I feel the amount of if-statements depends more on your class/code-design, like whether you use polymorphism correctly, interfaces, things like that.
But, to your point: You don't need to have everything perfect the first time. If you identified some valid contexts, you already did the hard part. If any context can be further divided, that could happen later anytime with little impact on others (since contexts are more or less isolated).
No specific business teams for different kinds of contracts
No dedicated dev team for specific kinds of contracts
Same ubiquitous language is used for all contracts
Every contract nearly follows the same process
These to me are signs that all contracts belong to the same business subdomain and should ideally be in the same Bounded Context - unless legacy or third party systems force you otherwise.
So I have few doubts regarding calling something as domain object (and eventually placing the class under domain package) or not.
I have a micro-service whose responsibility is to do some calculations (without getting into actual business requirements, all it does is calculate some return of intereset based on given request). Now to achieve the calculations there are certain sub-calculations which need to take place and hence are composed in different classes respectively. But yes, these calculation do not need to be persisted in DB , and neither they have an ID (so definitely not an Entity or Aggregate). However these individual calculator classes (for the lack of terminology) do contain some complex business logic. Now, my question is, do these individual classes still qualify/classify as domain objects or should they be referred to as services ?
Feel free to ask for more clarifications around use case if need be.
Cheers !
Now, my question is, do these individual classes still qualify/classify as domain objects or should they be referred to as services
From the DDD point of view, in the Domain layer, there are the following terms that could be implemented using classes: Domain entities, Aggregate roots (a type of Domain entity), Value objects and Domain services.
Because your things don't have an Identity they cannot be Domain entities or Aggregate roots. Calculations could be done inside Value objects or Domain services. Value objects contain specific behavior related to values so most probable your calculations are implemented using Domain services.
From my experience, not every domain class must be a DDD building block, they could be just classes extracted for better maintainability, Single responsibility principle (SOLID in general) etc.
A simple test could be asking below questions -
Does your “calculator” (as you refer it) hold the calculation result as an immutable state? — if the answer is yes then it is a Value Object.
Is the “Calculator” stateless and only exposes a “calculate” behaviour which accepts a request & returns a calculation result? — if the answer is yes then it is a Service, however, the “result” returned by this service may be classified as Value Object.
I would say that your calculations can fit well either in Value Objects or Domain Services.
How to differentiate? Well, I understand Domain Services as services (well, obvious) with business logic (such as your calculations) that require some kind of external dependency you need to inject in order to get your logic work.
On the other hand, if you can name that business logic as a business concept (i.e. CustomerFee, CustomerCommission, etc) and you don't need any injected dependency to make it work I would say it's a Value Object.
For instance, imagine that you want to calculate the price of a reservation which depends on the fee you will charge to the customer (among other params):
ReservationPrice(CustomerFee customerFee, ItemPrice ItemPrice)
Now your CustomerFee is also calculated based on (say any variable) something.
This way you are modeling your calculations just with Value Objects which allows you to show in your code all the different business concepts they depend on. Also anyone looking at your code and files structure can get an idea about what you are calculating.
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 would like to have one or more libraries of reusable classes that are basically value objects, such as Address, PhoneNumber, EmailAdress, containing mostly properties and a few supporting methods. How can my Domain layer use these without breaking the rule that the Domain Layer should not contain external references, and without defining them as interfaces/abstract classes in the Domain Layer?
... without breaking the rule that the Domain Layer should not contain external references
I think your definition of 'external references' requires some reevaluation. It is hard to imagine a domain layer that does not reference anything. In C# and Java you will reference at least basic numeric types, dates and strings. I also don't see any harm in referencing external libraries like Noda/Joda time. On the other hand, you of course would not want to reference any heavy technical libraries like persistence, communication, UI etc.
So I would say that you can build your own reusable library referenced from domain but it requires a very careful consideration, and is often not worth the coupling that it will create. I would use a following criteria for every type:
Should be context-independent. EmailAddress for example is relatively independent of the context it is used from. Address on the other hand may have a different meaning depending on a Bounded context.
Should be stable (does not change often).
Should not hide any out-of-process communication (db, network etc)
Should not have any dependencies of its own (other than standard Java/C#)
I think that what you're referring to is a shared kernel.
Shared Kernel – This is where two teams share some subset of the
domain model. This shouldn’t be changed without the other team being
consulted.
While this looks great at first, since we are drilled not to repeat ourselves, be aware of the pitfalls:
The concepts should have the same meaning in every context. Some of these concepts hold subtle nuances depending on the context. Ask your domain expert.
Changes are more expensive; it might be cheaper to duplicate these few classes so that you can change them on your own than to have to consult multiple teams when something changes.
Stability cuts both ways. If you pull an entity out into each domain, then any changes have to be executed across multiple projects. If you don't, then changes have to be coordinated across multiple domains. The logistics of the former are easier than the latter, but the work involved in the latter can be greater. Either way, you have to test the changes on each platform.
And unless the entity is mature with a relatively well-defined semantics, my experience is that almost everything changes. So stability is nice, but might be a bit of a red herring.
That being said, I like (and +1) #Dmitry.
What are DDD recommendations for inter-domain referencing design?
Should I try to connect them as "Matryoshka" (put one into another) or it is better to create upper-level "inter-domain" business service?
P.S. Crossing this smooth water, I was unable to find anything useful to read in the Internet, and have started thinking that for this kind of things exist better term than "inter-domain referencing"... Am I right?
DETAILS:
I have two models/business services.
Semantically first domain (A) is CRM with sell/maintenance process for our goods, second domain (B) is "design" data of our goods. We have two view points on our goods: from seller perspective and from engineer perspective.
Actually each model is effective ORM (Object-Relational Mapping) tool to the same database.
There are some inter-domain activities e.g. validations (e.g. sometimes we can sell things to smb. only if some engineering rules are valid).
From developer's point of view I have two clear possibilities (reference B in A or create new cross reference domain/service C ). But from designer perspective I am lost in understanding what kind of Business Service I have when I compose business logic from two different domains.
As far as I know, DDD has no strict rules for 'inter-domain' referencing. At the end of the day your domain model will have to reference basic Java or .NET classes. Or it may reference specialized date/time or graph library (aka 'Generic Domain').
On the other hand DDD has a concept of Bounded Context. And it has quite a few patterns that can be applied when you work at the boundaries of the system. For example 'Anticorruption Layer' can be used to isolate you from legacy system. Other integration styles can be used depending on how much control you have over external code, team capabilities etc.
So there is probably no need to introduce artificial glue layer if you just dealing with two subdomains in one Bounded Context. Might also be worth reading Part 4 of DDD book (Strategic Design).
UPDATE:
Based on the information you provided, it looks like you only have one Bounded Context. You don't seem to have 'linguistic clashes' where the same word have two different meanings. Bounded Context integration patterns are most likely not applicable to your situation. Your Sales domain can reference Products domain directly. If you think of Products domain being more low-level and Sales being high level you can use Dependency Inversion Principle. Define an interface like ProductCompatiblityValidator in Sales and implement it in Products domain. And then inject the actual implementation at the application layer. This way you will not have a direct reference from Sales to Products.
In addition to what Dmitry has already said...
I think of any code that crosses bounded contexts as application layer code. I would have that application layer code reference domain types from both contexts (and their repositories) but not have two domains reference each other. I think it's OK to have business logic in an application layer if it specifically crosses domain boundaries and is unit-testable.
If you really have a hierarchy, then it would be OK to have the the more concrete subdomain reference the more abstract domain. However, I would be careful if this causes you to need to have domain objects reference repositories of any type. Pulling objects out of of a repository is rarely a true domain concept. Referencing repositories is best done in an application layer that sits a layer above the domain model.
Of course this is all as much art as science. I'd try modeling a thin slice of your application a couple different ways and see what friction you run into with each approach.