Confused Between Layers when Using jmolecules-xxx-architecture

[aaryadewa]

Introduction

I am using AggregateRoot, Entity, Identifier, and some another basic ddd interfaces. The class implementing those interfaces actually is JPA entity, isn't? So that it also act as a domain object. So when I use it with conjunction to the jmolecules-xxx-architecture annotations, I have no idea where to put it into.

Cases

For example, if I put the ddd classes in the InfrastructureLayer, the domain model definition attached to it (e.g. AggregateRoot) becomes meaningless. But if I put them in the DomainLayer, then the repository, which is placed in the InfrastructureLayer, just cannot use the class just for the method declaration. The ArchUnit test becomes failed in this case.

Example

Given the Order aggregate root in the com.example.domain package.

package com.example.domain;

@DomainLayer
public class Order implements AggregateRoot<Order, OrderId> {}

Then I put the Orders repository (whether the interface or custom repository implementation) in the com.example.infrastructure package.

package com.example.infrastructure;

@InfrastructureLayer
public class Orders implements Repository<Order, OrderId>, AssociationResolver<Order, OrderId> {
    Order save(Order order);
}

The ArchUnit test is failed with this message:

...
where layer 'Domain' may only be accessed by layers ['Application', 'Interface']
where layer 'Infrastructure' may only be accessed by layers ['Domain', 'Application', 'Interface']' was violated
...
Method <com.example.infrastructure.Orders.save(com.example.domain.Order)> has return type <com.example.domain.Order> in (Orders.java:0)

How can I properly structuring my components?

[sth77]

In the onion architecture which you are using, the center of the onion contains the domain model. Domain driven design tells you to start your application design at this central ring, focusing on the model and on the business rules it implements, but keeping it free from any technical aspect such as database technology, message broker, REST API, etc. It gives you concepts to model the domain, such as entities, value objects, services or repositories.

The DDD annotations and types of jMolecules are means to express these concepts. So ALL OF THEM go into the domain ring of the architecture.

It seems that the concept of the repository confuses you. Isn't that where entities are persisted to a database? So shouldn't it be in the infrastructure layer?

The repository concept of domain driven design allows you to introduce an element to your domain which gives you access to one or more instances of an entity / of an aggregate root, or allows you to perform queries on them: findById, delete, countHavingExpiryDateInThePast(), etc. At the domain level, the repository is usually just an interface expressing the operations your domain model requires, and you do not care how it is actually implemented.

The implementation is then what goes into the infrastructure layer. Out here, you don't need DDD annotations, since the implementation is not part of the domain model. Your implementing class simply extends the repository interface declared in the domain ring and then does whatever is required to meaningfully implement the required functionality. Here you are free to depend on technical libraries such as a specific database driver or dealing with opening and closing transactions.

[aaryadewa]

It seems that the concept of the repository confuses you. Isn't that where entities are persisted to a database? So shouldn't it be in the infrastructure layer?

Exactly. It looks like that many diagram designs out there confuses me. Many of them describe that we use the infra layer to communicate the domain with the external resources, such as database, messaging system, etc. (ex. in the Layered architecture).
Thanks for the great insight, @sth77

[seekM]

I'm learning about this myself, so take this with a grain of salt, but this is my understanding:

The purpose of the Entities, Aggregates, Value Objects and Services patterns is to help modelling your domain. Therefore, domain concepts modelled by these patterns should be in the Domain Layer and be annotated with one of the Domain Layer annotations, e.g. @DomainLayer.

The repository (interface, at least) is part of the Domain Model as well. The best source for this I can come up with right now is this quote from the Blue Book by Eric Evans (page 124)

Although REPOSITORIES [...] do not themselves come from the domain, they have meaningful roles in the domain design. These constructs complete the MODEL-DRIVEN-DESIGN by giving us accessible handles on the model objects.

and that on the same page and the one before he also describes that domain objects have a life cycle and that repositories address the middle and and end of the life cycle.

If you choose to follow the Layered Architecture, the repository implementation will have to be part of the domain layer as well. It can't be part of the Infrastructure Layer, because in Layered Architecture the Infrastructure Layer is not allowed to depend on the Domain Layer (this is also stated in your ArchUnit test output; also see the diagramm in the Blue Book on page 68). The repository implementation then would use the Instrastructure Layer, see this quote of the Blue Book on page 155 (and example given):

The REPOSITORY will delegate to the appropiate infrastructure services to get the job done.

To my understanding, if you want the repository implementation to be in the Infastructure Layer, you would have to go for another architectural style, e.g. Onion Architecture. There it would be alloweded that the repository implementation resides inside the Infrastrucutre Layer and references the Domain Layer from there.

[aaryadewa]

Thanks, @seekM
You give me the point. So I can think now that the infra layer should be technically used as a low level layer to access the external resources then. For example is the low level implementation of how findById get the connection from the pool, run the query, etc.