Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Hexagonal Architecture + Domain Driven Design. How to perform a correct implementation?

+0
−0

Hello!

Currently, I am trying to implement these two architectures together with Java and Spring (although technology shouldn't matter I think).

But I'm encountering problems getting them to work together.

I understand that my application should have a structure with 3 layers and 2 zones (inside and outside the hexagon):

Domain: Entities that should be self-contained with their own functionality, Repositories, ValueObjects, Factories, Events, etc. This layer is the center of the hexagon.

Application: Where the ports should be found. I've also seen that this is where REST or "input" adapters are typically implemented. This layer is at the edge of the hexagon.

Infrastructure: the implementation of the output ports, where external libraries and frameworks should already be used. This layer is outside the hexagon.

But this raises several questions for me. Why are adapters typically implemented in the application layer or in the infrastructure layer, depending on whether they are input or output?

What do repositories and domain services do? Shouldn't these be in the application layer as interfaces, and infrastructure should implement them? After all, all the logic should go in the entity.

Right now I have this structure (after following several guides and reviewing some repositories on GitHub):

Shop (Base Module)

Shop-Domain (Submodule)
    src/main/java
    ├─── net.test.sell.domain
    │    └─── error (exceptions related)
    │    └─── model (Entities, ValueObjects, Events, etc...)
    ├─── net.test.workers.domain
    ....
 
Shop-Application (Submodule)
    src/main/java
    ├─── net.test.sell.aplication
    │    └─── ports
    |          └─── input (implementation of use cases)
               └─── output (interfaces for infrastructure submodule)
    │    └─── use_cases (interfaces)
    ├─── net.test.workers.application

Shop-Infrastructure (Submodule)
    src/main/java
    ├─── net.test.sell.infrastructure
    │    └─── database
    |          └─── adapters (implementation output interfaces)
    │    └─── rest_api(interfaces)
    |          └─── controllers (just REST Controllers)
    ├─── net.test.workers.infrastructure
    ...

I also have some questions regarding the most appropriate folder structure for this architecture.

Why do InputPorts use UseCases and OutputPorts are interfaces that are later implemented in infrastructure?

Is it a good practice to implement each small UseCase in a separate interface? Or can everything be done in one?

Finally. What is the correct naming convention for the different projects and packages?

Thanks in advance!

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.
Why should this post be closed?

0 comment threads

1 answer

+2
−0

Adapters are implemented in different layers based on their function. Input adapters (like REST controllers) are at the application's edge to handle incoming requests, while output adapters (like databases) are in the infrastructure layer, interacting with external systems.

Repositories and domain services are interfaces in the application layer, implemented in the infrastructure. Entities should handle the core logic, while repositories manage persistence.

For UseCases, it's often clearer to have separate interfaces for each, but you can combine them if they are related. Naming conventions vary, but consistency and clear, descriptive names are key.

Your structure looks well-organized. Stick to clear separation of concerns, and you'll be on the right track.

History
Why does this post require attention from curators or moderators?
You might want to add some details to your flag.

0 comment threads

Sign up to answer this question »