混淆有界上下文和子域

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/

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.

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.

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/

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

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”

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.

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?

1. Their current symptoms
2. Past medical records
3. 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

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.