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

61–70 of 74 posts

Re: Hexagonal Architecture and Domain Driven Design

#61

Post by Havelock »

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…

DDD is about building maintainable software by trying to separate the business domain from the application technology. If there is no separation and/or the software is not easy to maintain(more than just being tired of looking at it year after year), then try something else.

Re: Hexagonal Architecture and Domain Driven Design

#62

Post by iamwil »

I've been taking some time recently to do an exploration of programming, by reading programming history and ideas about different paradigms and domains. I started focusing on how our abstractions get destroyed at the boundaries of programs.[0] I was surprised to discover a link between Hexagonal Architecture and functional programming.

Both try to drive towards a functional core. With HexArch, you'd need an imperative shell to interact with the world at the boundaries. With pure FP, the boundaries are manned by I/O monads and effects manager in the underlying runtime. [1][2]

[0] https://interjectedfuture.com/destroyed-at-the-boundary/

[1] https://www.destroyallsoftware.com/screencasts/catalog/funct....

[2] https://deque.blog/2017/07/06/hexagonal-architecture-a-less-...

Re: Hexagonal Architecture and Domain Driven Design

#63

Post by nchi3 »

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 don't agree at all. They're very orthogonal concepts, and DDD has very little to do with OO. For an example, see Domain Modeling Made Functional.

Yes, if you do DDD in Java, you should probably follow OO principles. If you end up with a lot of classes "that do nothing", you've probably done something wrong along the way or you've applied it to something very simple where it didn't make sense to do so.

Re: Hexagonal Architecture and Domain Driven Design

#64

Post by c048 »

pydry wrote: post #36
loziuu wrote: post #33

Earlier quoted context omitted.

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…

I wish I could upvote you more than once. You hit the nail on the head, thank you.

Re: Hexagonal Architecture and Domain Driven Design

#65

Post by Tainnor »

cztomsik wrote: post #53
Tainnor wrote: post #39

Earlier quoted context omitted.

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) E…

Yes, you do need a certain level of indirection to achieve the things you mentioned without polluting your code with non-business concerns such as transactionality. But the key differences are:

1. Application startup is faster because you avoid reflection.

2. It's type-safe because you avoid reflection, so you get compile-time errors instead of startup errors (or worse, startup errors only in certain configurations).

3. It gives you more inspectable behaviour. You can see how the entrypoint of the application wires together components. A lot of this can be hidden, spread out over multiple places and hard to understand otherwise.

Also, I'm not the person you originally replied to, didn't call DI a circus, and actually think that DI is a useful concept per se (that some FP purists maybe under-appreciate): It could just IMHO be done in a cleaner way (and a more deliberate way, not everything needs to be wrapped in 5 layers :)) with functional constructs instead of reflection hell. :D

Re: Hexagonal Architecture and Domain Driven Design

#66

Post by berkes »

Tabular-Iceberg wrote: post #47
berkes wrote: post #35

Earlier quoted context omitted.

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

I'm quite certain that with some effort, and possibly some stretching of definitions, one can "do DDD with Rails".

But at that point you are going against the grain. You are both missing out on some good parts of Rails and spending a lot of time to work around or against what Rails wants and needs: Rails is very opinionated, don't forget that.

From https://en.wikipedia.org/wiki/Active_record_pattern#Criticis... > Another critique of the active record pattern is that, also due to the strong coupling of database interaction and application logic, an active record object does not follow the single responsibility principle and separation of concerns as opposed to multitier architecture which properly addresses these practices.[citation needed][clarification needed] Because of this, the active record pattern is best and most often employed in simple applications that are all forms-over-data with CRUD functionality, or only as one part of an architecture.[citation needed] Typically that part is data access and why several ORMs implement the active record pattern.

And a Rails without ActiveRecord, while technically possible, leaves you with a Rails that is hardly workable -if at all- and brings a lot of pain. Your application will live in ActiveRecord models, spread all over:

> ActiveRecord is meant to become the central part of your domain logic. -- https://solnic.codes/2016/05/22/my-time-with-rails-is-up/

So the answer would be: yes, this is necessarily the case. In practice and even in theory.

Re: Hexagonal Architecture and Domain Driven Design

#67

Post by hinkley »

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…

I think this is the impedance mismatch between the intellectual and the practical all over again.

More and more, when I find myself at odds with people it’s because one of us is trying to intellectualize a situation that cannot be safely intellectualized. Not that we have changed, but that my perspective has changed.

In disciplines with more physicality, “exercises” are used quite often and routinely denoted as being an artifice. Not all instructors do and not all students listen, and so YouTube is full of videos of martial artists getting their clocks cleaned for mistaking forms for sparring, sparring for fighting. Consultants recording/cleaning up construction or landscaping disasters created by ignoring the rules - or failing to think outside of the box. You could spend the rest of your life watching these kinds of videos and not see half of them.

I don’t want to do TDD all day every day. It’s infantilizing. But I’m a better developer for having done it, and when I feel the consequences starting to add up, I will do it again for a time, to knock the cobwebs off. You probably feel the same about DDD.

Re: Hexagonal Architecture and Domain Driven Design

#68

Post by dzikimarian »

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.

Well - apparently mine is one of them. Most of software we do, was built on some variation of DDD. Most of it is not very huge - maybe couple hunderds LOC.

Spliting it in managable hunks, that can be modfied independently and do not depend on framework, libraries and other 3rd party code minimizes headaches greatly, when customers want to overhaul some part of the business processes.

From time to time, someone says "it's to complex" which tipically means "Framework I like has this opaque feature which saves me two hours of work and you don't allow me to use it". Yet in the long run math is clear.

Of course it is tool and should be used for the right job. If something is CRUD, just use your favourite CRUD generator and do not pretend you need rocketship.

Re: Hexagonal Architecture and Domain Driven Design

#69

Post by Kototama »

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…

Not sure why you got downvoted.

Re: Hexagonal Architecture and Domain Driven Design

#70

Post by gunnarmorling »

Unfortunately, they only seem to implement read use cases in that example. I'd love to see how they implement writes with this architecture, as that is where things are getting more complex.

Either they'd make the entity model e.g. a managed (JPA) entity model, thus violating the hexagonal architecture approach, or they'd have a separate model for persistence, but then they'd have to synchronize all changes between the actual model and the persistence model, which depending on the size of the model may be come unwieldy, as they'd loose all the comfort of dirty checking in a managed object graph.

Post reply on HN