Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hexagonal Architecture and Domain Driven Design

towardsdev.com

Post reply on HN
Print view View original

11–20 of 74 posts

Re: Hexagonal Architecture and Domain Driven Design

#11

Post by regularfry »

davedx wrote: post #2

I 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…

It's not just keeping things separate, though. It's getting the dependencies in the right direction too. I'd argue that's actually the most important part. A lot of people would look at the decoupling in a hexagonal app (or something along the Clean Architecture lines - they're very similar) and say that you don't need that much decoupling, but the patterns are very powerful; deciding to opt into that power early is a good choice to make more times than you'd think.

Re: Hexagonal Architecture and Domain Driven Design

#12

Post by regularfry »

berkes wrote: post #7
shoo wrote: post #6

Earlier quoted context omitted.

> 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.

For the record you won't touch XML in Rails either!

Re: Hexagonal Architecture and Domain Driven Design

#13

Post by bruce343434 »

berkes wrote: post #9
shoo wrote: post #4

can 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" e…

non-architect here, what is this blue book you allude to?

Re: Hexagonal Architecture and Domain Driven Design

#14

Post by rapnie »

bruce343434 wrote: post #13
berkes wrote: post #9

Earlier quoted context omitted.

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" e…

non-architect here, what is this blue book you allude to?

"Domain-Driven Design: Tackling Complexity in the Heart of Software"

https://www.oreilly.com/library/view/domain-driven-design-ta...

There's also "Domain Driven Design, Distilled" providing a comprehensive summary.

https://www.pearson.com/us/higher-education/program/Vernon-D...

Re: Hexagonal Architecture and Domain Driven Design

#15

Post by regularfry »

shoo wrote: post #4

can 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…

Much though I dislike the author, I actually recommend the Clean Architecture book as an on-ramp for this stuff. CA is very similar to Hexagonal Architecture, and the book is more specific than any other source I've yet come across. It's written exactly with the goal in mind to tell you, clearly and unambiguously, what you should do and why, with as little room to manoeuvre as possible. That does make it a bit polemic, but when you're learning that's what you need.

It's also worth looking at Vaughn Vernon's books on DDD. The problem there is that what you end up building if you follow them to the letter ends up looking a lot less like the sort of applications that teams are used to building (which is good! The value is proportional to the level of surprise) so getting buy-in at the right stage of the process to do it properly can be hard. You need to get in at the conception stage, so if your team is used to having ideas dropped on them even partially formed, the struggle is entirely non-technical. If you try to sell DDD as "how to structure the code we're going to write now that the problem has been thought through" it's not going to work.

Re: Hexagonal Architecture and Domain Driven Design

#16

Post by rapnie »

davedx wrote: post #2

I 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…

It helps to separate DDD strategical parts from DDD tactical patterns. The first is really intuitive and broadly applicable, while on the second you get bombarded with a flood of information, opinionated approaches and OOP-y design complexity.

Re: Hexagonal Architecture and Domain Driven Design

#17

Post by shoo »

activitypea wrote: post #10

There'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.

you make a good point to keep things simple, "solve the problem you actually have not the one you wished you had". But, many of these ideas can have advantages even in small scale contexts. In some contexts they're not wins (e.g. extreme performance requirements might be prioritised over cost of future change) but in most situations where the cost of abstraction is negligible they're not a bad idea.

e.g. i've seen a gigantic technical mess created in a small company with less than a dozen staff -- that required a year of engineering effort to remediate -- because the application code of the company's product was not written to decouple the product's internal domain model from the external format controlled (and changed) by the first customer.

Re: Hexagonal Architecture and Domain Driven Design

#18

Post by Kototama »

davedx wrote: post #2

I 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…

Yes, incredible what years of Java Enterprise can inflict to the brain :-). It reminds me of the whole dependency injection circus where in the end it's just the equivalent of passing a function constructing an instance to another function in FP.

Re: Hexagonal Architecture and Domain Driven Design

#19

Post by c048 »

While I can get behind hexagonal architecture quite well, the more I use DDD the less I like it. It feels like doing DDD correctly is immensely difficulty, time consuming, makes code harder to read, etc... .

While everyone seems to want to do DDD, I've seen so many different approaches to it that always seem to slow down the projects as time moves on, because it becomes a constant struggle with the architecture. And for what? Benefits like a clear domain language that can be shared with the business does not require DDD. Most (if any) projects feel like they are ill fit for DDD.

"Ah, but that means you're doing DDD wrong!", I can already imagine a few people say. But I'd like to see one agreed upon approach to DDD that works when things start to get complex, rather than another super simple example that's supposed to sell you on the idea.

Re: Hexagonal Architecture and Domain Driven Design

#20

Post by Milner08 »

activitypea wrote: post #10

There'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.

I disagree, the company I work for is big but not massive and yet even using this kind of approach on a single product in our suite has been really beneficial. Its not as complicated as you may think, its just about keeping the code clean. Its allowed us to refactor technical implementations with much less risk and makes the code easier for people to follow. Sure it maybe a bit of a mental shift, but its not like you wont find benefits in it. (And I disagree with the insinuation that its more complex or slowing down development, I actually find the opposite is true).
Post reply on HN