Hacker News Reader

Comment by davedx | Hacker News Reader

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 framework, and not just web applications.

View on HN

> 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 in a room, they may argue over 25 different incompatible ideas of "sensible". Parnas suggests arranging things into modules so that changes or difficult decisions are isolated to single modules. Basically the same idea as S in SOLID. The D in SOLID suggests a concrete way to decouple things (interfaces!).

> This stuff should not need lists of XML config to get right

agreed. the key idea is to think about the dependency graph between modules. XML config & dependency injection & so on are some techniques for managing dependencies, but it is less important that figuring out a clean module design and module dependency structure that decouples the application.

Many possible candidate dependencies between pairs of modules should be banned as they would erode the architecture and add unnecessary coupling between things that need to change in response to different forces. With some extra knowledge about the purpose of each module, it should be possible to write a small validation tool that can inspect module dependencies and automatically fail the build if someone proposes to add a bad dependency.

https://en.wikipedia.org/wiki/SOLID

http://sunnyday.mit.edu/16.355/parnas-criteria.html

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

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.

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.

I can’t speak from experience, but the article you linked seems to make sense.

Rails appears to have very little to do with object oriented programming, except as an implementation detail. My point is that although Evans strongly recommends OOP for DDD in the blue book, it’s not a requirement.

If the first design phase of DDD, where you sit down with the domain experts, you might discover that what you are building is really just a CRUD app. Then it’s probably wise to actually use a CRUD framework, Rails or otherwise. You’re still using DDD, and you’re not even going against the grain or missing out on framework features.

When you make your database your model you delegate “decoupling from persistence” to the authors of your RDBMS. They have already decoupled it for you in that you’re not opening files and writing data, your INSERT statement is just stating facts about your domain.

I’ve explored the pattern of putting the entire domain model in the database in the form of constraints, triggers and queries that return JSON. The controllers just map URLs to queries, validate the input and just pass the result of the query to the client without looking at it.

It’s extremely powerful and productive. You never have to think about N+1. It’s more like logic programming than anything else. The downside is that SQL and associated tools aren’t terribly ergonomic, and it’s hard to find developers who are comfortable working like that.

I think part of the point is that if you are a Rails shop first, then trying to strap DDD on is only rarely going to work. If you are a "right tools for the job" shop who decide to do DDD as a primary tool, then there might be cases where it is what you choose.

Even if you are a Rails shop first, you can use DDD to determine if it's wise to take on the project in the first place. If it turns out that the domain cannot be expressed as a CRUD app, maybe refer the client to someone else. Then you will officially have used Rails with DDD, even if you haven't written a single line of Rails code for the project.

Much of DDD is really tech independent, and takes place before a single line of code is written. This is probably also where it's the most important. You're going to have to learn the domain first or the project will be a world of pain regardless of what architecture you choose.

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.

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 worry about any of that anywhere in your app (aka you are abstracted from this)

what you have said is not technically wrong but it also over-simplifies what DI is and it brings to the table

EDIT: that said, I agree in general, that java projects are over-engineered

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?

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

Oh, sorry for my misunderstanding then, I thought you were OP.

1. that's... not a problem for me 2. fair but you have tests & pipelines, so not a problem... for me :) 3. this is kind of fair, yeah

4. I absolutely agree about unnecessary layers, java engineers are the worst when they learn about something new and don't have enough practice yet

Not sure why you got downvoted.

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.

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.

The only XML in this article is about configuring Maven, the build system, though?

Reply on news.ycombinator.com