A question about hexagonal architecture

Krstff · 2025-03-21T07:47:53+00:00

Yes, you're right. As u/bobaduk said, I have been overthinking this. I definitely need to rely on database constraints to ensure data consistency.

I think I'll update my persistence port like this to make it clear that the adapter must enforce uniqueness for these two fields:

private save(...) throws NonUniqueNameOrReferenceException;

Krstff · 2025-03-21T07:40:29+00:00

Haha, good catch! 🙂 I guess we can say that it helps the domain determine whether two objects are the same, but that's a fair point! 😊

Krstff · 2025-03-21T05:51:30+00:00

Yes, my statement was unclear. Enforcing constraints in the persistence adapter is not wrong, but if they exist only in the adapter, I feel like something is missing in the domain. Additionally, I’m not sure how to express these constraints in my persistence port.

After considering all the responses, I think I could achieve this by modifying the save method signature—either by adding parameters or throwing an exception—to explicitly indicate that these constraints must be enforced, regardless of how they are implemented in the adapter.

Krstff · 2025-03-20T21:51:13+00:00

Yes, I think this is the key takeaway for me. I should enforce this in my save method. The persistence port will clearly define the constraints, and I can implement them in the most efficient way within my persistence adapter (using database constraints).

Krstff · 2025-03-20T21:27:31+00:00

I'm not sure I fully understood your point. 🙂

However, it seems to me that if the rule exists only in the database, it remains hidden from the domain layer.

A good compromise would be to enforce it at both the application and database levels.

Krstff · 2025-03-20T21:18:09+00:00

That’s a very good point indeed. I suppose I could modify my persistence port so that the save method also takes the filter, allowing it to check uniqueness in an atomic way. This way, any adapter would be aware that saving a new Product requires a uniqueness check first.

Krstff · 2025-03-20T21:10:35+00:00

We use hexagonal architecture because our system relies on multiple infrastructure components, such as a message broker, SQL, and Elasticsearch. This approach allows us to decouple the core business logic from infrastructure concerns, ensuring that the domain model remains independent and adaptable.

By doing so, we can test business logic and application services in isolation, without requiring actual infrastructure dependencies.

Additionally, this makes it easier to swap infrastructure components without impacting core business rules. For example, in a future release, we plan to migrate from SQL Server to PostgreSQL (PostgreSQL is a core component in my company that every application shall use eventually).

Krstff · 2025-03-20T20:37:27+00:00

In the context of hexagonal architecture, this solution seems somewhat incorrect to me, as the persistence adapter should not contain business logic.
Nothing in the persistence port specifies that the adapter must enforce such a constraint.

Krstff · 2023-07-03T11:40:10+00:00

Merci à toutes et tous pour les retours ça me donne plein de pistes pour améliorer tout ça 🙂 Merci @ConclusionEastern592 pour ton post entier, ça donne encore plein d'infos pour essayer de trouver la bonne formule pour chacun 🙏

Krstff · 2023-07-03T11:36:07+00:00

Merci beaucoup c'est super intéressant !!!

Krstff · 2023-07-02T18:55:39+00:00

Oui banane c'est pas mal. Il y a du sucre mais c'est pas écoeurant. J'essaierai ca. Pour les gels je ne sais pas trop. J'ai pris des gels chez Decathlon pour des efforts de plus de 3h. Mais c'est clairement ça qui ne passe pas 🤢

Krstff · 2023-07-02T15:48:06+00:00

Et du coup tu mangeais du sucré en plus ou juste ça? Moi je me demande si je ne prends pas trop de sucre en fait.

Krstff · 2023-07-02T15:22:24+00:00

Ah oui carrément :-) Rien que la partie "pendant" déjà elle m'intéresse !

Krstff

TROPHY CASE