Is limited context a complete application?

Question

I read about DDD and limited contexts, and I think I'm wrong. At first I liked the idea of ​​subdomains and limited contexts, I understood it this way: there is software that needs to be developed, but attacking everything at once is too much, so we break it into logical parts and develop it every time. Another problem we are solving is ambiguity in the ubiquitous language.

This made me think about limited contexts, because basically these are just folders in which I group and bind the code associated with a specific part of the application. This code, which I thought was made up of things like

• The domain model of this limited context, including abstractions for repositories and services
• The infrastructure level for this limited context, repository implementation, etc.

Of course, if the domain model and infrastructure are properly separated in a limited context.

Further, however, it seems that each limited context is a complete application at its discretion. It sometimes seems that each limited context has its own application layer, for example.

It confused me, because sometimes I don’t want to end up developing tons of applications, I’m the only one to develop it. The limited separation of application context was to create one application, and not many applications for integration.

I seem to have this question where @MikeSW claims that both approaches presented by OP are valid. I ask about the third structure:

<bc 1> |_ domain |_ infrastructure <bc 2> |_ domain |_ infrastructure |_ application |_ presentation 

At least for all the applications that I think it makes sense. I want one application, not several applications with several presentations, but I still want to be able to split the domain and take advantage of such things as the “ubiquitous language restriction”.

So, limited context - full application? Or can I use a limited context, as I understand it, and feel more useful? Have problems with my approach?

Answer 1

At the end of the day, the answer will be like that. The important thing that needs to be removed from a limited context is not how you structure your application, but that you have different spaces where you model specific behavior related to a certain context. How you define the boundaries between these contexts depends on the problem you need to solve.

There is nothing wrong with using namespaces (folders) to define restricted contexts. As you said, most of the time you just write one application. You can also define your limited context by having separate projects for each context. In this case, your presentation level will refer to the project he needs.

There are many correct ways to encode DDD. You must ask yourself: "I follow the basic principle, doing it like this"

Answer 2

The domain level is usually the most difficult part of your program and can also change often due to business requirements and refactoring. Thus, you generally do not want to expose it to a direct presentation level or other limited contexts. If you feel you can expose it, it may be that your application logic or case use methods are mixed with your domain level or that your program is small or complex to start with BC. Otherwise, I would include the application level in each BC to protect the integrity of the domain model and expose only the commands that need to be called from the perspective of use.

I want a single application, not multiple applications with multiple presentations, but I still want to be able to split the domain and capitalize on things like "restricting the ubiquitous language."

You can have a subtle application layer for each limited context and still have one presentation layer. This is sometimes called a “composite UI”, which in itself should be considered as a separate BC. If you need to process general logic, such as authentication, create another application service or facade in the composite user interface and process its authentication before, in turn, calling the external BC application service.

I think most of the examples that you see in books and on the Internet are overly simplified since they have 1 BC per physical running application (and do some network communication between them), whereas in the real world you can have a complex application that it is necessary to break it into separate logical units, but do not start them as separate processes, unless the need comes.

Answer 3

A limited context describes a subset of the complete solution, and everything in this context serves that context. Thus, imo, each context has its own domain, so it can be a separate application or just a subsystem of the same project. The point of "context" is that the ubiquitous language is applied directly in this context. For example, a user in the context of an account may mean something completely different than a user in the context of sales. Each "User" will have different capabilities and follow different rules in each context. Each context should be isolated from any other context and not allowed to exchange links (unless it is used in the "General" context); any communication should be mediated through a service that sits on top of this context. The context does not even have to follow DDD in order to be “DDD compliant”, since each context can follow its own approach (for example, domain-driven, data-driven, etc.). Contexts are simply silos that describe the logical part of a business.

Whatever you do to prevent direct references in contexts, does this mean that it means different namespaces, different assemblies within a solution, or different projects.

Answer 4

Limited context is the scope of the code. It relies on a domain model that ORM can support (or not). It implements various types of services (domain services and application services), but its purpose is to provide only domain services for its environment. DDD is a service-oriented architecture designed to work as autonomously and autonomously as possible. You may decide to use your services in different ways. The solution implements various types of components, various types of layers, various projects. I believe that the most important attention should be paid to the model, which should not be distributed among the components. Solution design and domain model are orthogonal.