Hexagonal Architecture and Domain Driven Design • Hacker News Board

Re: Hexagonal Architecture and Domain Driven Design

#51

Post by caffeine » Tue, Apr 12, 2022, 12:30 PM UTC

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…

> they are best served by code that represents their understanding of the business

Genuinely curious why you think this is? To me it seems a massive leap?

Trying to steel-man this, if:

1. The people who know best about the domain are not technical and don’t know algorithm thinking

2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it

This is basically the consulting scenario, which is where DDD came from (?) Then it would make sense - when the team leaves and the next guy comes in with no clue how it works, he can read it out to the domain expert who will roughly understand what it’s doing.

On the good teams I’ve seen, the domain experts and the people coding are the usually same people, the “domain vocabulary” is CS, and the team is looking for maximum leverage (trying to do with 10 ppl what others do with 100 people).

So it’s quite a different scenario than 100 ThoughtWorkers getting dropped into some vertical they know nothing about and being expected to model a bunch of existing business processes.

Re: Hexagonal Architecture and Domain Driven Design

#52

Post by vladsanchez » Tue, Apr 12, 2022, 12:36 PM UTC

discreteevent wrote: post #32

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…

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

Did you refer to [Patterns, Principles, and Practices of Domain-Driven Design](https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...) by Scott Millet and Nick Tune?

It's the only similarly titled Wiley book. Thanks for sharing.

Re: Hexagonal Architecture and Domain Driven Design

#53

Post by cztomsik » Tue, Apr 12, 2022, 12:49 PM UTC

Tainnor wrote: post #39

cztomsik wrote: post #30

Earlier quoted context omitted.

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

Yes but unfortunately I don't see how it invalidates my point.

a) you either replace DIC with custom hard-wired functions (composed using any-order custom helpers) and then it's still hard-wired at one place

b) you reinvent DI with functions but it's still some magic, late-configurable, easy-to-plugin container (aka the circus which I think you were referring to and which I have said it's actually useful and worth)

EDIT: or what exactly are you complaining about?

Re: Hexagonal Architecture and Domain Driven Design

#54

Post by rapnie » Tue, Apr 12, 2022, 1:22 PM UTC

dagw wrote: post #49

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

Can absolutely recommend watching that video.

Re: Hexagonal Architecture and Domain Driven Design

#55

Post by eweise » Tue, Apr 12, 2022, 1:40 PM UTC

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 never found domain driven design to be an extension of object oriented design or microservices. Its mainly a way of organizing your code so it doesn't turn into a big ball of mud at some point.

Re: Hexagonal Architecture and Domain Driven Design

#56

Post by rowls66 » Tue, Apr 12, 2022, 1:53 PM UTC

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…

I disagree partially. I do agree that modeling your domain in programming language objects and then transforming those objects into data stored relational tables (OR Mapping) is not a great design. However, DDD can also be done where the relational database is the model of the domain, and the application is merely a set of functions that execute SQL and transform the results. So based on the application two approaches for persistence are possible:

1) Model the domain in the programming language, and store data as opaque blobs. 2) Model the domain in relational tables, and use the application logic to extract and transform the data.

Re: Hexagonal Architecture and Domain Driven Design

#57

Post by phphphphp » Tue, Apr 12, 2022, 1:54 PM UTC

caffeine wrote: post #51

phphphphp wrote: post #46

Earlier quoted context omitted.

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…

> they are best served by code that represents their understanding of the business Genuinely curious why you think this is? To me it seems a massive leap? Trying to steel-man this, if: 1. The people who know best about the domain are not technical and don’t know algorithm thinking 2. The technical people are not capable of understanding the domain enough to separately discuss what the code does and how it does it Thi…

Everybody within a business should be using the same language and concepts when thinking about the business, because it's important for effective communication: daylight between what people are thinking about is where problems creep in. The role of any people of any discipline within a business is to use their expertise to shape _how_ they think about the shared _what_.

Code is just one tool (of many) that a business will use to achieve its goals. There's a mythology in a lot of businesses around the genius of technologists because we understand the complex system that we built that everybody else in the business is too dumb to understand, but in reality it's because technologists are uniquely permitted to decide they're better than everyone else and diverge from the shared thinking because it's easier than reconciling business concepts with technology -- which is where the actual hard part of software engineering is!

If you walk into any business that has been around for a few years and has allowed their technology team to do whatever they want, you'll probably find a completely incomprehensible system that the business hates because it has diverged so far from how they think and what they want that they can't effectively do their jobs.

People come and go, the only constant in a business is the business.

An example that comes to mind is a business that has customers who pay for membership, and so they're called "members" within the business. However, the development team decided they knew better and implemented "user" accounts which can have a "subscription". Then, later, the business decided to introduce a subscriptions product... and so the problems began.

Re: Hexagonal Architecture and Domain Driven Design

#58

Post by karmakaze » Tue, Apr 12, 2022, 1:57 PM UTC

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…

DDD seeming as an extension to OOP is no co-incidence. An intro page[0] for author Eric Evans shows:

> Eric Evans is the author of “Domain-Driven Design: Tackling Complexity in Software,” Addison-Wesley 2004.

> Since the early 1990s, he has worked on many projects developing large business systems with objects with many different approaches and many different outcomes. The book is a synthesis of that experience. It presents a system of modeling and design techniques that successful teams have used to align complex software systems with business needs and to keep projects agile as systems grow large.

[0] https://nofluffjuststuff.com/conference/speaker/eric_evans

Re: Hexagonal Architecture and Domain Driven Design

#59

Post by falcolas » Tue, Apr 12, 2022, 2:16 PM UTC

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

Damn. Talk about calling out my team. Like, perfectly describing our current project.

And, as expected, even correct unit tests will randomly fail.

Sigh.

Re: Hexagonal Architecture and Domain Driven Design

#60

Post by zmgsabst » Tue, Apr 12, 2022, 2:32 PM UTC

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’m not sure I understand this comment — aren’t the two different things?

DDD is a business-to-software paradigm to decide what software to build, defining the relevant terms — what the data is, how it’s used, etc.

DOD is a framework for turning that map of relationships into a technical implementation, as you can see from the inputs to DOD being the outputs of DDD.

I see it as frontend (DDD) and backend (DOD) in a compiler chain of business needs to technical system.