Hexagonal Architecture and Domain Driven Design
towardsdev.com
Hexagonal Architecture and Domain Driven Design
1–10 of 74 posts
Re: Hexagonal Architecture and Domain Driven Design
#2I think the underlying principles of DDD and Hexagonal Architecture are sound, but man, they make it so complicated. A good serving of KISS always helps.
- Keep your domain models separate from infra implementation stuff
- Architect your applications in sensible layers
- Decouple stuff that doesn't strictly belong together
This stuff should not need lists of XML config to get right, it's portable to any language or framework, and not just web applications.
Re: Hexagonal Architecture and Domain Driven Design
#3No post body was provided.
Re: Hexagonal Architecture and Domain Driven Design
#4can anyone suggest links to reading about DDD & hexagonal architecture that clearly spells out: which context each pattern applies to ; what problem each pattern aspires to solve ; what advantages and disadvantages applying the pattern can have. bonus points for suggesting alternative patterns or linking to case studies / post-mortems / war stories / peer-reviewed empirical software engineering research of how these things turned out in practice.
edit: here are some articles that are clearer:
https://netflixtechblog.com/ready-for-changes-with-hexagonal...
https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-a...
Re: Hexagonal Architecture and Domain Driven Design
#5I think the underlying principles of DDD and Hexagonal Architecture are sound, but man, they make it so complicated. A good serving of KISS always helps. - Keep your domain models separate from infra implementation stuff - Architect your applications in sensible layers - Decouple stuff that doesn't strictly belong together This stuff should not need lists of XML config to get right, it's portable to any language or f…
The only XML in this article is about configuring Maven, the build system, though?
Re: Hexagonal Architecture and Domain Driven Design
#6I think the underlying principles of DDD and Hexagonal Architecture are sound, but man, they make it so complicated. A good serving of KISS always helps. - Keep your domain models separate from infra implementation stuff - Architect your applications in sensible layers - Decouple stuff that doesn't strictly belong together This stuff should not need lists of XML config to get right, it's portable to any language or f…
> Keep your domain models separate from infra implementation stuff
this is a corollary of the S in SOLID -- domain models and infra implementations will have different reasons to change at different times, so they should be decoupled
> Architect your applications in sensible layers > Decouple stuff that doesn't strictly belong together
Agreed, but this isn't prescriptive enough, if you put 5 opinionated stakeholders in a room, they may argue over 25 different incompatible ideas of "sensible". Parnas suggests arranging things into modules so that changes or difficult decisions are isolated to single modules. Basically the same idea as S in SOLID. The D in SOLID suggests a concrete way to decouple things (interfaces!).
> This stuff should not need lists of XML config to get right
agreed. the key idea is to think about the dependency graph between modules. XML config & dependency injection & so on are some techniques for managing dependencies, but it is less important that figuring out a clean module design and module dependency structure that decouples the application.
Many possible candidate dependencies between pairs of modules should be banned as they would erode the architecture and add unnecessary coupling between things that need to change in response to different forces. With some extra knowledge about the purpose of each module, it should be possible to write a small validation tool that can inspect module dependencies and automatically fail the build if someone proposes to add a bad dependency.
Re: Hexagonal Architecture and Domain Driven Design
#7I think the underlying principles of DDD and Hexagonal Architecture are sound, but man, they make it so complicated. A good serving of KISS always helps. - Keep your domain models separate from infra implementation stuff - Architect your applications in sensible layers - Decouple stuff that doesn't strictly belong together This stuff should not need lists of XML config to get right, it's portable to any language or f…
> Keep your domain models separate from infra implementation stuff this is a corollary of the S in SOLID -- domain models and infra implementations will have different reasons to change at different times, so they should be decoupled > Architect your applications in sensible layers > Decouple stuff that doesn't strictly belong together Agreed, but this isn't prescriptive enough, if you put 5 opinionated stakeholders…
> This stuff should not need lists of XML config to get right
I'm "doing" DDD in "hexagonal monoliths" for years now. And have never touched a line of XML.
The XML is caused by Java (more specific its Maven build system). You'll hardly touch any XML when you build your projects in Go, Ruby (not rails!), Rust or many other languages or platforms.
Re: Hexagonal Architecture and Domain Driven Design
#8can anyone suggest links to reading about DDD & hexagonal architecture that clearly spells out: which context each pattern applies to ; what problem each pattern aspires to solve ; what advantages and disadvantages applying the pattern can have. bonus points for suggesting alternative patterns or linking to case studies / post-mortems / war stories / peer-reviewed empirical software engineering research of how these…
If you’re using Python, I’d recommend Architecture Patterns with Python by Harry J.W. Percival and Bob Gregory.
Re: Hexagonal Architecture and Domain Driven Design
#9can anyone suggest links to reading about DDD & hexagonal architecture that clearly spells out: which context each pattern applies to ; what problem each pattern aspires to solve ; what advantages and disadvantages applying the pattern can have. bonus points for suggesting alternative patterns or linking to case studies / post-mortems / war stories / peer-reviewed empirical software engineering research of how these…
I presume you haven't read the "blue book"? Because that covers many of what you ask.
In addition, the canonical (but not clearest, IMO) source on Hexagonal architecture is by the "inventor" himself: https://alistair.cockburn.us/hexagonal-architecture/. Several links in that article are dead now, but some still work and point to excellent discussions and articles.
If you are looking "war stories" or "case studies" especially in a setting where management or colleagues need some convincing, this article of how Netflix employs it might help https://netflixtechblog.com/ready-for-changes-with-hexagonal.... I've -depressingly, actually- found that often people are easier convinced by an argument "BigCorp™ does it too" than by "its good because of X".
Recently a more practical post landed on HN. It includes CQRS, which might make it more convoluted than what you need, but even with that, it has some really nice "lessons learned" and "best practices": https://herbertograca.com/2017/11/16/explicit-architecture-0...
(ninja-edit: weird sentence fixed)
Re: Hexagonal Architecture and Domain Driven Design
#10There's maybe 20 companies in the world that benefit from this kind of architecture. Everyone else is just being an architecture astronaut or inventing for invention's sake.