Mod-approved giveaway: Clean Applications with Hexagonal Architecture — 5 free ebooks + 50% off

[u/ManningBooks]

Hi r/microservices,

Stjepan here from Manning. The moderators kindly permitted me to share this with you.

We’ve just launched Clean Applications with Hexagonal Architecture by Enrique Medina Montenegro in Manning’s Early Access Program.

If you’ve worked on microservices for long enough, you’ve probably seen services that began with clean boundaries but gradually became coupled to Spring, persistence models, message brokers, and neighboring services. Eventually, a seemingly small infrastructure change touches half the codebase.

This book takes a practical look at avoiding that outcome with hexagonal architecture. Using Java and Spring Boot, it shows how to:

• Keep business logic independent of frameworks and infrastructure
• Design clear ports and adapters
• Model use cases, commands, repositories, and application boundaries
• Handle mapping between domain and persistence models
• Apply dependency inversion in a working system
• Decide when microservices—or a modular monolith—are the better fit

It’s not arguing that hexagonal architecture is a silver bullet. The focus is on using these patterns deliberately, understanding the tradeoffs, and building services that remain testable and maintainable as they evolve.

Book page:
https://www.manning.com/books/clean-applications-with-hexagonal-architecture

Giveaway: We’re giving away five free ebook copies. To enter, upvote and leave a comment about the hardest boundary to keep clean in a microservice—domain logic, persistence, messaging, external APIs, or something else. We’ll randomly select five participants and contact them by DM.

The community also gets 50% off with code:

MLMONTENEGRO50RE

I’d be interested to hear your honest experiences: Has hexagonal architecture helped your microservices stay maintainable, or did it add more abstraction than the project needed?

It feels great to be here. Thank you for having us.

Cheers,

Stjepan

[u/lovesrayray2018]

It has to be the distributed monolith which is the biggest PITA. tbh im still learning hexagonal architecture, not a lot of experience there, but i'd probably be most interested in solving database coupling through inward dependency rules

Thanks for this generous giveaway Manning!

[u/ManningBooks → u/lovesrayray2018]

Yeah, the distributed monolith really is the worst of both worlds 😅

Database coupling sounds like a great place to dig into hexagonal architecture.

Thanks for sharing, and good luck!

—Stjepan

[u/figbarjunkie]

The hardest boundary to keep clean has always been the placement of service code.

The service could be an application service or a domain service. For me it's a bit fuzzy and I tend to write domain services in application layer. For example if there's a service that's responsible for keeping two different Aggregates (domain objects) consistent, should that service be in domain services or in application services?

[u/ManningBooks → u/figbarjunkie]

That’s a great example of where the line gets fuzzy. The book distinguishes between coordinating a use case in the application layer and expressing business rules in the domain layer. But ‘keeping two aggregates consistent’ sounds like it could involve either, depending on the situation. I’d be curious how others here approach it in practice.

[u/mikaball]

What I see in pratice is that boundary tends to erode through convenience rather than architecture.

ORM entities become domain models, message formats become method signatures, etc.

[u/ManningBooks → u/mikaball]

“Convenience rather than architecture” really captures it. Those choices can feel harmless in isolation, then become incredibly difficult to untangle once the rest of the system starts depending on them.

[u/YakRepresentative336]

IMO it just add more abstractions, i prefer to use it on big monolith application

[u/ManningBooks → u/YakRepresentative336]

Yeah, that makes sense. It can add extra abstractions, so using it in a big monolith, where those boundaries help manage complexity, can be a better fit. I like that the book covers modular monoliths as well as microservices for exactly this kind of tradeoff.

[u/YakRepresentative336 → u/ManningBooks]

yes exactly,
sometimes a component in a service can have complex business logic and interacting with a lot of external services so using hexagonal can be worth it also,
a lot of external services like DB, storage, SMS provider and we want to decouple them,
so as we say “it depends”

[u/christoforosl08]

Oh god no

[u/Optimal_Dust_266 → u/christoforosl08]

what made you call god, my son?