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

41–50 of 74 posts

Re: Hexagonal Architecture and Domain Driven Design

#41

Post by wvh »

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…

All these architecture and workflow methods (Agile, scrum, TDD, DDD, Kanban, even 12-factor) have a few useful and logical concepts at their base. Then people create a dogmatic religion around them, often without even understanding the why.

An experienced and reasonably intelligent person usually has no difficulty in figuring out which concepts are most relevant for a given project to increase its changes of success. In reality, that person just ends up fighting adherents of the chosen corporate or hive-mind dogmatic religion or finds themselves surrounded by people in pure ignorance of matters beyond throwing code over the proverbial wall.

You should not "follow" agile or DDD. You should understand its concepts and apply them when suitable, as part of a broad toolkit – as with anything in life.

Re: Hexagonal Architecture and Domain Driven Design

#42

Post by kebsup »

I've worked on a project with similar setup: Gradle packages for API, domain and infra and it was one of the nicest developer experiences I've had for backend. Better than classic monolith, in which people sometimes put stuff wherever without respecting the boundaries or microservices, which were pain to develop when multi-service communication was involved.

The cherry on top was when one of my junior collegues told me that he was struggling, since the project did not let him use dependency, that did not make sense.

Re: Hexagonal Architecture and Domain Driven Design

#43

Post by projektfu »

For me an important insight of hexagonal architecture is to treat the database as either an implementation detail or a first class citizen. If you need a reliable store of data to provide your application, it doesn't matter externally how it looks. If you need to run crystal reports or support OLAP, you had better treat it as a consumer with its own stories and functional tests. Of course there can be public and private parts of the database, treated differently.

Re: Hexagonal Architecture and Domain Driven Design

#44

Post by hsn915 »

caffeine wrote: post #38

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

> It’s a great way for a huge team of programmers to write a massive amount of code that doesn’t do very much

Yea. I often hear the excuse "it's for many lines of code written by large teams" but what's often ignored is that all this code is not doing much actually.

Data Oriented Design is a breath of fresh air.

Re: Hexagonal Architecture and Domain Driven Design

#45

Post by [deleted] »

activitypea wrote: post #26
shoo wrote: post #17

Earlier quoted context omitted.

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…

You're a 100% right with that example, I just think it's important to pry these apart as separate issues. The issues you faced should've been solved by a simple data transformation at the system boundary. "Don't let external data formats permeate through your codebase" is, to me at least, basic engineering intuition. There's no deeper meaning to be gleamed from that, the team lead displayed gross incompetence and now…

[deleted]

Re: Hexagonal Architecture and Domain Driven Design

#46

Post by phphphphp »

caffeine wrote: post #38

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

I agree very much that DDD is an extension of OOP in many ways, but very much disagree that DDD (or OOP) is synonymous with "lots of code". OOP (like any principle) is easy to misuse/abuse when doing it for the sake of it, and so personally I'd discourage OOP (and by extension, DDD) for anyone who isn't confident that it fits their model of thinking, nor if they're unaware of the pros and cons... but good OOP (what little of it exists) is very powerful as a way to translate business logic into code. Most non-technical people do not talk about data, and do not think about programs as data transformation, they think about their domain, and they are best served by code that represents their understanding of the business, not some developers decision about how their business is best represented using data.

Essentially, I'd describe DDD as high risk, high reward, and so for most businesses, it's not the right decision. However, if you have a talented and experienced team that deeply understand both the business and programming, then DDD is a great opportunity.

Re: Hexagonal Architecture and Domain Driven Design

#47

Post by Tabular-Iceberg »

berkes wrote: post #35
regularfry wrote: post #12

Earlier quoted context omitted.

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.

I haven't used Rails before, so I may be missing something, but is this necessarily the case?

If I remember correctly the blue book isn't too keen on modelling your domain in your database, but rather build it out of POJOs and then build a separate layer. But at the same time it's open to using DDD with a logic paradigm, which is eerily similar to a relational database. If, after you've done the necessary work with the domain experts, you have determined that Rails is the right tool for a job, I think you can safely call it a paradigm and carry on.

Re: Hexagonal Architecture and Domain Driven Design

#48

Post by dagw »

phphphphp wrote: post #46
caffeine wrote: post #38

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

I agree very much that DDD is an extension of OOP in many ways, but very much disagree that DDD (or OOP) is synonymous with "lots of code". OOP (like any principle) is easy to misuse/abuse when doing it for the sake of it, and so personally I'd discourage OOP (and by extension, DDD) for anyone who isn't confident that it fits their model of thinking, nor if they're unaware of the pros and cons... but good OOP (what l…

I agree very much that DDD is an extension of OOP in many ways

May I recommend the video Domain Modeling Made Functional: https://www.youtube.com/watch?v=9QlhkQl0DSw

and the book on the same topic: https://pragprog.com/titles/swdddf/domain-modeling-made-func...

Scott Wlaschin has been on a "crusade" for years to decouple DDD from OOP and show that doing DDD in a functional language (he uses F# for all his examples) is not only possible, but preferable. He might not change your mind, but it will make you look at DDD from a new angle.

Re: Hexagonal Architecture and Domain Driven Design

#49

Post by dagw »

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…

When it comes to DDD, I highly recommend the book Domain Modeling Made Functional and the lectures the author has given based on the book: https://www.youtube.com/watch?v=9QlhkQl0DSw

Those two resources where the ones the led to really get and appreciate DDD. One thing I really liked about them is that all the examples are in F# (the functional part of the title) and so manages to make it clear how DDD and OOP are decoupled and how DDD doesn't necessarily imply OOP.

Post reply on HN