A delimited context only has domain model code?

Question

Reading about delimited contexts in DDD I was in doubt if this is an idea that relates only to the domain model layer or if this is an idea that involves more parts of the application. I’ll explain better.

From what I understand, in Area Code we have the idea of subdomain, which is basically a way of partitioning the domain itself, that is, a concept of the problem space. On the other hand, as I understand it, a delimited context is a delimited part of the solution space, that is, it serves to delimit a region of applicability of a certain model with its ubiquitous language.

It turns out I saw a video recently by Vaughn Vernon in which he compares delimited contexts to Visual Studio solutions for an analogy. But in a solution there is much more code than just the domain model code.

So, what really lies within a bounded context? Is it just domain model code? Or is there more? I’m thinking this way:

In the domain model there are not only entities, objects of value and aggregates, repositories, factories and services. Thinking about the use of DDD with OO, what would be there would actually be interfaces. For each interface (IRepositorioProdutos for example) I need an implementation, clearly in a separate project from domain types. This implementation may depend on infrastructure (the repository depends, for example, on EF).

In that case, within the context all that: domain types, necessary abstractions, implementations and the necessary infrastructure? Or would only be the domain model even in that context?

Answer 1

When delimiting a context, we take into account the domain and not the infrastructure that will serve it.

Thus, the Sfraestruture is not part of a delimited context.

See, a system can meet very complex business rules and at the same time have a very simple infrastructure, and the same infrastructure could meet the whole system and not just one or another delimited context; so it makes no sense infra and context to be encapsulated together.

What is contained in a Solution from a defined context?

I don’t know the video mentioned, but a way to organize a Domain-Driven system "Designed" in Visual Studio would be to create a Solution for each delimited context. But each of these Solutions would not contain the necessary infrastructure but only references to infrastructure assemblies and configurations, which would be used during debugging and testing.

So, what really lies within a bounded context? Is it just domain model code? Or are there more things?

To Solution of a delimited context would then contain all the business objects of that context, and some of these objects would be there in the flesh (interface and concrete implementation) and some would only be in interface in case the implementation is provided by the infrastructure. The infrastructure appears in this Solution only in the form of referenced assemblies and configuration files.

Eventually the infrastructure or part of it is also developed within the team, in this case its sources would be organized on their own Solutions.

For each interface (Irepositorioproducts for example) I need an implementation, clearly in a separate project from domain types. This implementation may depend on infrastructure (the repository depends, for example, on EF).

In this statement lies a risk. The Entity Framework wants to speak the language of the domain; the proposal is that we consume the EF in our business code and not in our infrastructure code.

We need repository after all?

There are those who defend the extinction of repositories when using EF. See:

var equipamentosEmOperacao = 
        (from eq in context.Equipamentos
        where eq.EmOperacao == true
        select eq).ToList();

What is the advantage of abstracting the above search for an interface IEquipamentosRepositorio.ObtemEquipamentosEmOperacao and hence write this code in a concrete implementation that will be obtained by injection of dependency and blah blah blah? Possibly no advantage and so it may be better to dispense with this useless complexity.

But our rules are complex otherwise we would not be worried about DDD; so it is not a flag that determines whether an equipment is in operation but rather a combination of factors: the reference date needs to be understood by the initial and final date of the scheduled operation, the equipment must not be marked inactive, the measurement of INMETRO must not be overdue and the reference date must not correspond to a maintenance period either.

So I ask: will I repeat a complex query every time I need it or abstract it to a repository? I will definitely abstract to a repository, and in addition to avoiding code duplicity I will still have the benefit of grouping in a single interface all* business rules contained in getting the entity.

_{*All business rules that are part of this particular delimited context.}

That is to say: Using EF with complex business rules, what can be extinguished are Daos and not repositories. In DDD, repository is not DAO - it is not there to abstract CRUD, it is there to abstract rules of obtaining and persistence of complex entities, assuming that if entities were not complex you would not need DDD.

The concrete implementation of the repository belongs to the domain or infrastructure?

The factors that determine whether an equipment is in operation are business rules, are determined by the business expert, so they belong to the domain.

Then, the concrete implementation of IEquipamentosRepositorio.ObtemEquipamentosEmOperacao, using Entity Framework, it certainly belongs to Solution of its delimited context. It belongs to the domain and not to the infrastructure. The implementation of the RU itself belongs to the infrastructure, but it is already naturally abstracted from its business code.

Completion

A delimited context has only domain model code?

Bounded context is a concept that exists beyond Visual Studio - it is known even from the business expert. On the other hand, when we organize the code of a delimited context in Visual Studio, it is natural to create a Solution for each context, and in this case only the domain code resides in this Solution. The infrastructure is available through referenced assemblies and configuration files to be used during debugging and testing.

Another important point is that the concrete implementation of repositories, especially when using RU, belongs to the domain and not to the infrastructure.