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

31–40 of 74 posts

Re: Hexagonal Architecture and Domain Driven Design

#31

Post by scns »

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…

Sadly not a blog post, but i can recommend this book [0] by Scott Wlaschin. Just finished it today, the last four chapters show how easy it is to incorporate changing business requirements.

[0] https://pragprog.com/titles/swdddf/domain-modeling-made-func...

Re: Hexagonal Architecture and Domain Driven Design

#32

Post by discreteevent »

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…

This book doesn't cover hexagonal architecture but I found it clearer and less verbose than the blue book. The first half of the book is on strategy and emphasizes its importance. It's a way of thinking that you can use with any architecture. It also makes it clear that only a subset of your system is suitable for DDD (not the CRUD bits for example). https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...

Re: Hexagonal Architecture and Domain Driven Design

#33

Post by loziuu »

c048 wrote: post #19

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…

The main point is that language you use to talk business should be used to write code. I don't get how using ubiquitous language can slow down the projects.

> clear domain language that can be shared with the business It does not work like that. Business share their lanaguage with you, not other way around.

Most important thing in DDD is Domain Expert. He's the cental point of strategic DDD. If you don't have one, then you either have CRUD app (which you shouldn't use DDD for - stick with ADM) or you can just use something called "DDD Lite" which is often referred to as "OOP done right".

Also, main problem w DDD (or any architectural approach) is that you have to make biggest architectural decisions when you basically have the least amount of knowledge about the system/problem.

Re: Hexagonal Architecture and Domain Driven Design

#34

Post by mkl95 »

In my experience DDD works best when using minimal frameworks where you are free to implement most of the architecture. If you are using an opinionated ORM like Django or Rails, applying DDD can easily lead to adding layers of abstraction for the sake of it.

Ultimately, DDD is just another tradeoff, and it comes with a hefty price tag that imo is not worth it for small companies. It's not going to magically prevent your developers from delivering buggy or unstable software, and it's not going to teach your product team how to write proper requirement documents.

Re: Hexagonal Architecture and Domain Driven Design

#35

Post by berkes »

regularfry wrote: post #12
berkes wrote: post #7

Earlier quoted context omitted.

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

Correct!

Why I emphasized the not rails! part was to avoid confusion about DDD, Hexagonal and Rails. I'm convinced Rails cannot and will not be usable in a DDD setup, or Hexagonal architecture. Well, maybe if Rails is the "HTTP interface", but you'll be fighting tooth and nails to make it not use a database.

Re: Hexagonal Architecture and Domain Driven Design

#36

Post by pydry »

loziuu wrote: post #33
c048 wrote: post #19

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…

The main point is that language you use to talk business should be used to write code. I don't get how using ubiquitous language can slow down the projects. > clear domain language that can be shared with the business It does not work like that. Business share their lanaguage with you, not other way around. Most important thing in DDD is Domain Expert. He's the cental point of strategic DDD. If you don't have one, th…

>I don't get how using ubiquitous language can slow down the projects.

It doesnt. Ubiquitous language is more or less just a reworking of system metaphor from XP and was a fine idea even then but DDD took the idea, barely tweaked it and layered a bunch of quite horrible design patterns around it.

Ubiquitous language and bounded contexts are the best parts of DDD by far but theyre also the least original and the least well developed concepts and honestly DDD doesnt have much of anything interesting to say about either one of them beyond what they are and that theyre important.

Re: Hexagonal Architecture and Domain Driven Design

#37

Post by Tainnor »

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.

You can use gradle with Java (no XML), and even if you use maven, your pom.xml won't have much to do with your application logic, so I'm not exactly sure where this idea comes from that you need XML to do DDD in Java.

Re: Hexagonal Architecture and Domain Driven Design

#38

Post by caffeine »

It’s a shame that Domain Driven Design and Data Driven Design have the same acronym, while being basically polar opposites (some people call the latter Data Oriented Design for this reason).

To me, Domain-Driven is sort of an extension of Object-Oriented fundamentalism that used to reign, especially in the Java world. You make a class or a micro-service for every concept in your world.

It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much (there are always exceptions, of course!) - with elaborate contortions to model and name everything just right. You might wind up needing things like Dependency Injection frameworks, mocking frameworks for tests, etc.

Data-Driven is the idea of leaning in to the fact that fundamentally, your software is a program, running in computers. It is going to turn some input into some output. You design along the axis of what data you need, how it is represented, where it needs to go, what transformations need to be applied, what output needs to be produced, and what needs to be stored. It tends to look more like functional programming, although you can certainly also apply mutating transformations, usually for efficiency.

IMHO, the latter is a great way for smaller teams to produce modest amounts of code that accomplishes a great deal.

Re: Hexagonal Architecture and Domain Driven Design

#39

Post by Tainnor »

cztomsik wrote: post #30
Kototama wrote: post #18

Earlier quoted context omitted.

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.

except the container can do whatever mumbo-jumbo you may want/need, like declarative transactions, declarative permission checks, logging, publishing events to external systems, etc. and then you have async constructed dependencies, for example when you need to ask some server for configuration first, before service can be started, and with a good DIC the whole app will just wait automatically and you don't have to w…

Most of these things can be done with higher-order functions too.

I think that if Java had had lambdas earlier, Spring and other such frameworks might look very different. You can see that already, Spring is adding (experimental?) support for more declarative styles of configuration instead of the rather slow and hard-to-debug reflection magic: https://github.com/spring-projects-experimental/spring-fu

Re: Hexagonal Architecture and Domain Driven Design

#40

Post by kebsup »

NicoJuicy wrote: post #28

The article and the comments are missing the most important thing. For DDD don't use SQL as your database. Postgress ( and eg. The excellent library martendb for dotnet) are perfect for this. Dump ( or update) your object to the db and the ability to query some properties ( so you don't need an additional search service to query your data - https://martendb.io/documents/indexing/duplicated-fields.htm... ) Using SQL i…

Could you elaborate a little more on this? What kind of headaches do you have in mind? (No pun intended :D)
Post reply on HN