"XDD" for all X is overrated, in the sense that the ideas attract adherents who use them as the hammer for all nail-looking things. Yet the best way to present any XDD principles is to ignore the rest of the world and alternative approaches, otherwise you'll get bogged down in all the qualifications and exceptions and lose the central thread of what you're trying to communicate. The article is probably correct that bringing in DDD specialists on every design question is a mistake -- the use of DDD specialists ought to be to teach designers another way of doing design, then leave it up to them whether to apply it case-by-case. Same thing with TDD, the other D(data)DD, etc.
The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor.
Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.
radicalbyte 1146 days ago [-]
You need to understand the context that birthed DDD. It was a reaction to the model of building business logic into UI event handlers which was pushed hard at the time by the Visual Basic (and java equivalent) crowd in businesses.
Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it.
I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
dang 1146 days ago [-]
I don't think that history is right. Martin was talking about Eric's work and crediting him long before Eric's book came out. I saw Martin give a talk just before PoEAA came out and he was telling people to wait for Eric's book to get the richest take on domain modeling.
DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being much less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'.
DDD wasn't the only thing that emerged this way, of course. Quite a few Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the latest of these to emerge because he spent years working on that book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)
radicalbyte 1146 days ago [-]
Martin's books formalised learnings of others - including those from the Smalltalk community - and PoEAA acts like a good map to the works of information systems.
When I say that "Eric took that idea and ran with it", I mean that Eric went into a lot of detail on the Domain Model (and wrote the definitive book on it). Given the way that Fowler (and Thought Works) work I wouldn't be surprised if Eric was one of the main sources.
Both books had a great impact on me, and they're both on the reading list I give to developers I'm mentoring.
Properly applied DDD is extremely effective, just using Bounded Contexts is extremely valuable (i.e. taking a high level view of your enterprise, putting logical boundaries in place and accepting different abstractions in different contexts).
dang 1145 days ago [-]
> just using Bounded Contexts is extremely valuable
Eric would be happy to hear that. I think he felt that the later chapters of the book, on strategic design, got insufficient attention. Ubiquitous language only applies within a bounded context!
huseyinkeles 1146 days ago [-]
What is GoF book?
detaro 1146 days ago [-]
"Design Patterns: Elements of Reusable Object-Oriented Software". also called the Gang-of-Four or GoF book for the four authors.
huseyinkeles 1146 days ago [-]
Thanks!
kqr 1146 days ago [-]
I'm a big fan of Carlo Pescio's musings. Thanks for the link!
rtpg 1146 days ago [-]
One thing I heard recently, that I found pretty true when role-playing in my mind, is that most of the design methodologies get like... 90% of their value from forcing _a_ methodology onto people.
The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc.
Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.
I have read similar thoughts on psychology. Makes sense to me.
linsomniac 1146 days ago [-]
Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.
HighlandSpring 1146 days ago [-]
Something tells me that in 2021 a lot more people will identify DDD to mean Domain-Driven Design than the concept that you mentioned
kristopolous 1146 days ago [-]
I was literally introduced to that term with this article while I've been using ddd off and on for 20 years
Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.
Like this from wikipedia:
"An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.
People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."
I mean holy hell, did a markov chain write that?
Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.
In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.
It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.
I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.
In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!
Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.
Go work on harder problems, seriously
FieryTransition 1146 days ago [-]
Agreed, sounds like they are trying to say that two people in different settings can make changes without understanding the reasons. It could also be summed up with, "go talk to each other"
kristopolous 1146 days ago [-]
I summarize all those theories as "how to be a human". There's all these tech business books with titles like "Lean Innovation" and they must be written for people without the crudest socialization skills.
It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant things"
I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"
fenderbluesjr 1146 days ago [-]
I encourage you to read more.. Your take on the wikipedia article reads as as you had your decision made up beforehand. The words he uses, which you think are too elaborate, have specific definitions within the context of the book. Your 'summary' missed the mark completely
kristopolous 1146 days ago [-]
Of course they do. That's part of the theater.
Some things are genuinely complicated and others are intentionally so.
This is clearly something that is complicated by choice, not by necessity.
All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.
They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.
I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.
It's a "type", more rare than others, but they're out there.
If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.
FieryTransition 1146 days ago [-]
I think the problem is that these methods and authors are heavily incentivized to make a name for themselves and a framework which can become a business somehow.
There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.
If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.
coldtea 1146 days ago [-]
Your comment is a little funny because Domain-Driven Design is a concept, whereas DDD is an actual software that has existed for decades (a GDB front-end)....
buzzerbetrayed 1146 days ago [-]
Something tells me that even more people would identify Domain-Driven Design as Domain-Driven Design.
cozzyd 1146 days ago [-]
"man ddd" would disagree
speaking of which, ddd is the only application I have installed that relies on motif...
linsomniac 1146 days ago [-]
Wow, Motif. Speaking of overrated... I had mostly blocked it out of my head.
bjohnson225 1146 days ago [-]
You’re probably right, but it’s still better to spell it out in the title when a good percentage of readers will either be unfamiliar or think of something else.
thetopher 1146 days ago [-]
I was thinking of the debugger too. I was also surprised to see it described as “overrated” since it’s ratings have never been that good.
andi999 1146 days ago [-]
I thought it meant Data Driven Design.....
mixmastamyk 1146 days ago [-]
I was thinking of a fully digital audio recording, digital mixing, and digital mastering. :-)
That buggy thing is also probably overrated. I'm just not sure how people rate it.
kenniskrag 1146 days ago [-]
naming is hard :D
kgwgk 1146 days ago [-]
:DDD
Toine 1146 days ago [-]
If anything, i find that DDD is underrated and underused. But i can totally imagine projects where it goes completely over the top, like anything (frameworks, patterns, microservices, Redux -oh god Redux-, whatever)
Happened the exact same thing with agility when it became Agile™
pm 1146 days ago [-]
Sounds like the difference between agile and Agile. It helps to understand the domain when you're architecting a solution, but I didn't realise there was an extended nomenclature around it. I thought it was just a conceptual phrase.
1146 days ago [-]
systemvoltage 1146 days ago [-]
Author talks about how DDD is overrated and gives a couple of arguments about nomenclature.
The real issue seems to be in plain sight in the article:
> But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts
That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument.
The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl.
I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.
mathiasverraes 1146 days ago [-]
These articles are pretty much impossible to disagree with, because they follow the same pattern.
Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.
§1
Clickbait title
§2
Tool X is popular. I'm a fan. Tool X is useful.
§3
It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.
§4
There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.
§5
Conclusion: Not all things require Tool X.
(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.
It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.
Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)
sfvisser 1146 days ago [-]
I’ve never explicitly used DDD, but I am convinced there is great value in having an obvious abstraction barrier between a domain core and your application and UI layer. It will allow you to pivot the UX quickly without compromising your core idea.
However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects.
Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely.
With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’.
All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
notretarded 1146 days ago [-]
But you only know that through experience of developing against said practices...
ChicagoDave 1146 days ago [-]
I think this article skips the most important aspect of DDD.
Reducing Complexity.
If you’re building simple systems, you don’t need DDD and Evans has always been clear about that.
But when you have a complex system, using DDD to “pull it apart” is highly effective.
What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools.
DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans.
It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities.
DDD isn’t just about root aggregates and value objects.
It’s a communication tool and a pretty damn good one.
franciscop 1146 days ago [-]
On the other hand, "Documentation Driven Design" is definitely underrated and an excellent way to end up with a very nice API.
einpoklum 1146 days ago [-]
> definitely underrated
Good documentation is under-rated; not sure about designing via the documentation.
> excellent way to end up with a very nice API.
My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
franciscop 1146 days ago [-]
Sure you might not be able to write 100% of the documentation in one go and then the code, but AFAIK that's neither the goal or the intention of DDD, it's more like "document a bit, write a bit, repeat".
The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.
Examples of libraries I've written mostly this way:
The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it.
The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.
kristopolous 1146 days ago [-]
Engineering is like 50% about what you actively choose to not do, 40% making sure nobody else does it, and 10% doing it.
playing_colours 1146 days ago [-]
Thanks for sharing the article! The idea of making a framework for executing business logic that can be dynamically defined by users is old. It is realised in rule engines, embedded scripting, DSLs.
As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.
Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.
Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.
Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.
Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.
virgilp 1146 days ago [-]
One of the things that rubs me wrong are articles that present a solution with no downside. Even if I were to mostly agree with the article you quoted, surely there must be downsides to the "functional architecture"? And, sure enough, it's fairly easy to come up with them:
a. Configuration complexity: if your system is generic & simple, sometimes the complexity doesn't go away, it just moves. As in the excel case quoted by the author - sometimes those excel files become a horrible unmaintainable mess that just produce wrong results and nobody can really tell. Sure, your architecture is nice, but did you make life good for the users? There's something to be said about the qualities of domain-driven software, here...
b. Performance (as opposed to scalability). It's often much harder (though not impossible!) to optimize the system if it's business rules are written in the configuration. Try doing machine learning in excel... it's theoretically possible, right? And yes you can get better performance by scaling horizontally to some extent, but then you risk running a hard-to-maintain-and-costly distributed system instead of a single machine that could do everything well.
HarmonicTons 1146 days ago [-]
If the flaw of DDD is that there is no emphasis on when not to use it, then the flaw of Peter's article is that, according to him, you should never use it ("software should be designed around function rather than domain").
I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.
Also: "someone who should not communicate with humans" is a little bit too much.
mjgs 1146 days ago [-]
You make some valid points, but “good ideas written by someone who should not communicate with humans” - a bit harsh don’t you think?
stevebmark 1146 days ago [-]
After reading all 500 grueling pages of DDD, that could have been 50 pages, no, I do not regret my hyperbole.
I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.
At least it was hyperbole, thanks fir the clarification.
stepbeek 1146 days ago [-]
I love technical reading but found DDD a really hard book to get through. I've been meaning to read the Vaughn Vernon books to figure out if they're an easier read for when I feel like I need to refresh my memory.
xupybd 1146 days ago [-]
Have you tried Scott Wlaschin's book. It's a very easy read.
The way I see it is that DDD works well with very consolidated process modelling. Think finance, insurance, but also e-commerce, billing systems, etc.
If your business is for example into "data" processing or in the discovery phase at a startup, then I can see how DDD can feel like ultra over-engineering. But it has its place, for sure.
mathiasverraes 1146 days ago [-]
> The biggest flaw of DDD I've run into is there's no emphasis on when not to use it
Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.
xupybd 1146 days ago [-]
That article misses some important nuances. Yes hard coding business logic can land you in hot water. But you don't need to do that domain driven design. What you do need is the domain to specify the flexibility of your design. Almost all business need an accounting system. An accounting system can be built following domain driven development. But for it to be useful to many businesses it must be flexible. So the rules around standard accounting ( the domain ) will be hard coded. But the system can still be configurable as the domain is too.
bopbeepboop 1146 days ago [-]
To elaborate —
Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.
In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.
So you’d build your system to match:
- A foundation of transacting assets/currency/inventory
- A system for defining transaction flows
- A system for reporting transaction aggregates (eg, for tax filings)
Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.
Like most good ideas, people get way too formulaic about it sometimes.
arwhatever 1146 days ago [-]
Interesting to see all of the discussion on hard-coding vs configuring domain/business logic, when in reality most line-of-business app developers are never introduced to the very concept of business/domain logic, and therefore it gets strewn all throughout an application’s code based, tangled in with data retrieval, u/i concerns, and everything else.
bopbeepboop 1146 days ago [-]
Yes — the goal of DDD is to explain why that’s a bad idea. For two reasons.
1. It makes your code a mess.
2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?
DDD argues you should develop software by:
1. Talking to customers about the domain until you have a shared language with specific terminology.
2. Write that down as a model.
3. Write that model as software.
I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.
DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.
kthejoker2 1146 days ago [-]
This is literally why Fowler and Evans wrote their books, some of this "tangling" was viewed as a feature because it let a single dev own an issue and avoided the bottleneck of architecture by committee.
1146 days ago [-]
metanonsense 1146 days ago [-]
Like many things that have the potential to make you feel clever, e.g. machine learning, functional programming, DDD can easily be overused / used for the wrong reasons, at least if it's not mastered to a certain level.
When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.
At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".
Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.
hardwaresofton 1146 days ago [-]
The author is a fan of DDD (despite the title) and so am I. In fact I'd argue that DDD is just about the only way that you could possibly do work that can be categorized as "systems design". You either do it with the knowledge of the common sticking points of DDD or you don't.
If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be.
What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
Me too. I think it is quite old too, going back to 80's?
stepbeek 1146 days ago [-]
This feels like clickbait. It seems like the conclusion is something like “DDD done well is really good, but not perfect” which I can’t take action on. Maybe a concrete example of when it doesn’t work well would help?
I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
NicoJuicy 1146 days ago [-]
What he probably means ( he doesn't go into details), is that you can create a simple monolith without splitting up everything.
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
I think it is often more helpful to ask the question "To what extent is XDD useful in context Y?". This firstly shifts the discussion away from whether something is universally good or bad (the space of bandwagon riders and hype curve surfers), and secondly avoids trying to comment on what one believes to be the popular opinion at some particular point in time.
Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.
zn44 1146 days ago [-]
This is a perfect hn, reddit blog post. Controversial title catching points even if people don't read it. Simple contents that are easy to disagree with and broad topic that has a lot of meta. Karma production machine
scott_w 1141 days ago [-]
I’m a bit late to the party on this but the article fundamentally misunderstands DDD. DDD explicitly doesn’t concern itself with implementation details. It doesn’t have an opinion on DB servers, how you should partition data, etc.
DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application.
If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.
donzampano 1145 days ago [-]
DDD has the same foundation as Agile:
Complex problems (domains) require explorative and iterative aproaches (like science always did), complicated or simple domains don't need that.
And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too.
For me, that's both timeless wisdom, and nothing special.
pachico 1146 days ago [-]
This article says nothing about DDD and all about how the author is coping with its gaining traction.
I myself find DDD a pilar I don't want to work with anymore.
scoopertrooper 1146 days ago [-]
It seems that their primary gripe relates to the naming of certain concepts. The article does not support the headline.
1146 days ago [-]
dman 1146 days ago [-]
I came here expecting a critique of the DDD debugger :(
namelosw 1146 days ago [-]
My organization was in the hype about DDD for years, so I practiced it for quite some time. I would say many parts of it is overrated. But there's still great parts. Here's what I learned:
1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture
2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it.
3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help.
4. You don't have to adopt Microservice combined with DDD.
5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful.
The Good:
1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind.
2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices.
3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design.
The Bad:
1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry.
2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler.
The Ugly:
1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive.
3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.
valenterry 1146 days ago [-]
> 1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model
I think that is a crucial point. In fact, the platform _is_ very often part of the domain and should be part of the language in DDD. It's one of the reasons why no-code solutions fail and why there is often a mismatch between developers and product-team - the latter does not see these things as part of the domain, but they are and if you don't describe them as it, there quickly is a mismatch between dreams and reality.
namelosw 1146 days ago [-]
> I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
Pretty much like it. There's a popular pattern called Tagless Final which lets you parametrize it and then swap the implementation in the last step.
In this way the model layer wouldn't know the underlying implementation is Future, Promise, or Flux. Sometimes it's useful because the developer finds it's painful to migrate from libraries to libraries.
twirlock 1146 days ago [-]
People talk about DDD and mean two mutually exclusive things depending on the scenario. It's either an excuse to have domain concepts pervade your whole stack or it's a description of clearly labeling your models. The prior seems like a naive, bad idea, especially when used with traditional OOP.
02020202 1146 days ago [-]
tl;dr but i wholeheartedly disagree. i can live without the lingo but the concepts are incredibly important. especially in large and complex projects. even though, in essence, it is all merely about encapsulation of data and actions that can be performed with/on them within context. it is good to have some general understanding of what is actually being done, conceptually. and having a philosophy with a name helps.
HelloNurse 1146 days ago [-]
DDD principles are very helpful and "robust" but they address, specifically, untangling complex domains and requirements: sometimes it's the main software design challenge, but often other aspect of architecture that DDD doesn't have a lot to say about are much more difficult and/or important.
For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.
PostThisTooFast 1146 days ago [-]
DDD never made sense. You HAVE to have a digital master, so the last letter will always be D. Only the first two letters tell you anything: digital recording, digital mix.
fattire 1146 days ago [-]
Was I alone in reading this as Dalton's Disk Disintegrator being overrated?
1146 days ago [-]
stevejb 1146 days ago [-]
I thought "Diners, Drive-ins, and Dives"
sarvasana 1146 days ago [-]
Not even going to read it, because of the stupid click bait title.
enriquto 1146 days ago [-]
It was a great debugger in its time, with some unique features. True, its development was abandoned at long time ago, but saying that it is "overrated" seems a bit unfair.
29athrowaway 1146 days ago [-]
The article is about Domain Driven Delopment, not the ddd debugger.
Rendered at 12:04:34 GMT+0000 (Coordinated Universal Time) with Vercel.
The best DDD-related thing I've read is the paper "Programming as if the domain (and performance) mattered": https://drive.google.com/file/d/0B59Tysg-nEQZSXRqVjJmQjZyVXc... One of the lessons I took from it is that too often as programmers we look at a problem and immediately try to transform it to some other problem, typically in a more abstract domain. Often this is fruitful, and our formal education (not to mention whiteboard-hazing interview practices) centers around pounding this into our heads with reusable data structures and algorithms. But also often it leads to something harder to evolve, not as fit for the original purpose, and more confusing (especially to those unfamiliar with the abstractions used). If DDD does nothing but make us challenge that default mode of thought and consider not doing problem transformation immediately every time, it's a worthwhile endeavor.
Another resource I widely recommend is the book Thinking Forth (http://thinking-forth.sourceforge.net/) It has many lessons applicable today on software design, including some useful thoughts on a program's "lexicon" that are somewhat DDD-related.
Originally Fowler documented the domain model in PoEAA, then Evans took the idea and ran with it.
I agree that the book hasn't aged well: like the GoF book it's a slog to read. Evans isn't Fowler.
DDD was born from Eric's roots in Smalltalk development. When Smalltalk got supplanted by Java there was a strong desire to find ways of building Java systems that could recover at least some of that development style, such as domain modeling, despite the technology being much less flexible. At the time it had sort of the feel of 'preserving what we can of civilization after the apocalypse'.
DDD wasn't the only thing that emerged this way, of course. Quite a few Smalltalk programmers became influential programming teachers in the post-Smalltalk world (Fowler, Beck, Cunningham). Eric was probably the latest of these to emerge because he spent years working on that book. (It's been years since I've read it but my impression was always that it was unusually well written. It's true that you have to read it as a book to really get it, which is kind of a lot to ask nowadays.)
When I say that "Eric took that idea and ran with it", I mean that Eric went into a lot of detail on the Domain Model (and wrote the definitive book on it). Given the way that Fowler (and Thought Works) work I wouldn't be surprised if Eric was one of the main sources.
Both books had a great impact on me, and they're both on the reading list I give to developers I'm mentoring.
Properly applied DDD is extremely effective, just using Bounded Contexts is extremely valuable (i.e. taking a high level view of your enterprise, putting logical boundaries in place and accepting different abstractions in different contexts).
Eric would be happy to hear that. I think he felt that the later chapters of the book, on strategic design, got insufficient attention. Ubiquitous language only applies within a bounded context!
The barebones "top-down"/"bottom-up" strategies most of us start up with is basically no good at forcing us to plan things out. But other strategies cause design errors to bubble up more quickly, so we can fix them, ship stuff that's right the first time etc.
Anyways I guess I just feel like you can totally mix-and-match design methodologies to your problem space, so long as you're actually applying it seriously enough (and have some agreement with stakeholders about it). But I do feel like too much discussion on these topics focus on failure cases and "false practice", and don't really end with actionable advice.
Reading wikipedia it looks like one of those trivially stupidly obvious concepts wrapped in overly wordy academic terminology where they invent imaginary distinctions that have no differences in lived reality.
Like this from wikipedia: "An individual bounded context leaves some problems in the absence of a global view. The context of other models may still be vague and in flux.
People on other teams won't be very aware of the context bounds and will unknowingly make changes that blur the edges or complicate the interconnections. When connections must be made between different contexts, they tend to bleed into each other."
I mean holy hell, did a markov chain write that?
Let me translate: "yo, some specs are more locked down than others so try to make the code more flexible for the parts that are likely to change" that's it.
In my experience people that wrap simple stuff in academic potpourri get absolutely nothing done and generate really defective bloated software at very high cost because their code is written in the same way: simple things done in confusing and incomprehensible ways.
It's as if someone covered something as dumb as rocks with the maximum amount of bullshit possible where you can still just barely translate it to comprehensible English.
I'm surprised there's no set theory equations in that wikipedia page, maybe a bit of lambda calculus. We should get on that.
In fact, let's make a tool where you define your contexts in Haskell and then run it over your code like a linter to generate GraphML files so someone can run it through graphviz and print it out to put it on their wall to have in the background during their stand-ups so they can make themselves look super professional. Who cares if your deadlines slipped another month, you're clearly an authority!
Other industries, like hairbraiding require certificates and licenses to protect their jobs. In software, instead, apparently, some people ornately festoon simple things with fancy language and hide it behind acronym soup.
Go work on harder problems, seriously
It has flow charts, diagrams, tabular statistics, you know, to conclude groundbreaking things like "talking to at least one customer before releasing a product is a smart idea" or "don't waste time on unimportant things"
I'm like "Dude, did you just want a section for your CV that says 'Recent Publications'?"
Some things are genuinely complicated and others are intentionally so.
This is clearly something that is complicated by choice, not by necessity.
All that "complicated by choice" leads to is fundamentalism and orthodoxy. People worry about whether their code matches the new sacred scripture over whether it works and then they shoehorn things into the form that don't belong there.
They bake meaning onto code that's way out of scope of the project. It's like programmers Gematria.
I've seen these all-knowing preachers write broken code and leave unmaintainable dumpster fires in their wake my whole career. Giant cathedral messes that barely do anything that all the customers complain about with endless academic blabbering everywhere and very little to show for it.
It's a "type", more rare than others, but they're out there.
If the results are better and the systems work sign me up. But if it's just another church of code with mere ceremony and internal logic, then yeah, have fun at mass.
There's a serious lack of scientific rigour in these areas, and from my experience, it's heavily driven by popularity. Besides, i still don't see a reason why you could not explain things in simpler terms.
If you get smart people together who can communicate well, think for themselves and don't stand in their way, it will always outperform any method. But this is so painfully obvious, that no one will pay you to say that. And there's really no cookie cutter recipe to achieve that, anyone who tells you otherwise, probably has something to sell.
speaking of which, ddd is the only application I have installed that relies on motif...
https://en.wikipedia.org/wiki/SPARS_code
The real issue seems to be in plain sight in the article:
> But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts
That's the issue, their own experience has been terrible but I don't see any specifics about why domain driven design is terrible. Provide an example. Go through the rigor of your arguments. Show us some code, something concrete, tell us a story about how it was painful to them and what was the impact - whatever is needed to make a strong argument.
The problem with articles like this is people read up on it, make their mind, and now you have a sloth of people converted to "Anti-DDD religion" will become painful to deal with at work because they read up some HN article about how DDD is overrated. It gets stuck in their minds like cereal in an empty milk bowl.
I expect more from the author after saying "There, I said it." Totally ok to be anti-DDD, would love to hear more though.
Every tool, concept, or technology, that aims to address a common need, will eventually reach the point in their adoption curve where an author publishes a hot take.
§1 Clickbait title
§2 Tool X is popular. I'm a fan. Tool X is useful.
§3 It annoys me that everybody(1) treats it as the golden hammer. A single tool is not enough.
§4 There are other tools. We can even make more tools. The best Tool X users use many other tools. You can't shoehorn all problems into Tool X.
§5 Conclusion: Not all things require Tool X.
(1) The term "Everybody" is used, because the author doesn't want to name the individuals or group that caused the annoyance.
It is definitely a pattern because if you’ve been around tech, you’ve read numerous of these articles. I doubt they achieve their goal. I think we need ways to help people avoid golden hammers, without merely pointing at the hammer.
Interestingly, Eric Evans’ work includes heuristics on when not to use DDD, and a call to action to find many more patterns than the ones he lists :-)
However, I’m not entirely convinced this needs to be encoded in tech very rigidly. Especially not for starting projects.
Just make sure the vision in in your head is clear and clearly communicated to the entire team. As long as you know what you’re building ‘conceptually’ the chance of your code base becoming a mess is way less likely.
With every line of code you need to know/feel either ‘this is core to our product/domain’ or ‘this might change in a year or so’.
All the DDD/solid/kiss/services whatever paradigms are secondary to having a clear tech and product vision.
Reducing Complexity.
If you’re building simple systems, you don’t need DDD and Evans has always been clear about that.
But when you have a complex system, using DDD to “pull it apart” is highly effective.
What you build from the parts is subject to that rule as well. If you end up with ten boundaries and some of them are simple, use simple tools.
DDD isn’t a religion. It’s meant to get architects to stop designing monoliths that we know have costly lifespans.
It’s also meant to get us modeling with our business partners with tools like Event Storming and truly understanding strategic opportunities.
DDD isn’t just about root aggregates and value objects.
It’s a communication tool and a pretty damn good one.
Good documentation is under-rated; not sure about designing via the documentation.
> excellent way to end up with a very nice API.
My experience suggests otherwise. I've found that both the code and the documentation "write themselves" at different points of development, progressing logically until they hit some snag or question-mark, with each of them effecting the other side in somewhat unexpected ways - so that working on just one side first is not the right thing to do.
The way I do it is first write a draft of the documentation, of how I want the API to look like. Then check if that basic code is possible (which I can predict most of the times based on experience), then write some more docs or methods. When writing a lib I normally already know where I want to use it, so I can put example snippets from how I want to use it as the documentation first and then try to implement those methods.
Examples of libraries I've written mostly this way:
- https://github.com/franciscop/brownies
- https://github.com/franciscop/files
- https://github.com/franciscop/backblaze
Or “literate programming”
The biggest flaw of DDD I've run into is there's no emphasis on when not to use it. There's no mention that over-coding business rules into modules and services locks you into businesses processes that are slow or impossible to update. There's no mention that most times you want to build services that offer platform capabilities, not focus on what "domain" they fall into. Nevermind that "domain" is basically undefined and can mean many different concepts and different types of concepts. DDD has some decent and good ideas, and is over extended to "this is how you should set up everything." Build more platforms where the domain logic exists in user land, not in code land. Everyone will be more productive for it.
The book Domain Driven Design is also terribly written. Good ideas written by someone who should not communicate with humans.
As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.
Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.
Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.
Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.
Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.
a. Configuration complexity: if your system is generic & simple, sometimes the complexity doesn't go away, it just moves. As in the excel case quoted by the author - sometimes those excel files become a horrible unmaintainable mess that just produce wrong results and nobody can really tell. Sure, your architecture is nice, but did you make life good for the users? There's something to be said about the qualities of domain-driven software, here...
b. Performance (as opposed to scalability). It's often much harder (though not impossible!) to optimize the system if it's business rules are written in the configuration. Try doing machine learning in excel... it's theoretically possible, right? And yes you can get better performance by scaling horizontally to some extent, but then you risk running a hard-to-maintain-and-costly distributed system instead of a single machine that could do everything well.
I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.
Also: "someone who should not communicate with humans" is a little bit too much.
I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.
Here a smaller one: https://github.com/engma/ddd-inanutshell
Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-func...
Just because I personally like the pragprog site.
Thanks!
Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.
Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.
In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.
So you’d build your system to match:
- A foundation of transacting assets/currency/inventory
- A system for defining transaction flows
- A system for reporting transaction aggregates (eg, for tax filings)
Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.
Like most good ideas, people get way too formulaic about it sometimes.
1. It makes your code a mess.
2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?
DDD argues you should develop software by:
1. Talking to customers about the domain until you have a shared language with specific terminology.
2. Write that down as a model.
3. Write that model as software.
I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.
DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.
When I first learned about DDD in 2008 or so, I was so proud of myself that each and every service was DDDified, which really put a huge mental burden on me and my team. It is not only that you have to think really deeply about your domain (which is usually a good thing) but you often come to a point where doing things the DDD way means a lot more work, e.g. creating Anti-Corruption Layers between bounded contexts. I spent so much time researching if I do things correctly and if the acknowledged prophets consider a design decision acceptable that coding started to hurt.
At some point however - and I think this what happens whenever you master something sufficiently - the penny dropped that the subtitle of the Eric Evans book "Tackling complexity in the heart of the software" really meant something: that DDD was a method for building complex software. The book itself - if you read it carefully as I did many years later - says explicitly that you should not use DDD for most parts of your system but only complex "core domains".
Nowadays, I am designing most services as "Transaction Scripts" again. Without feeling guilty.
If you're writing a subroutine in a device driver or some other similarly specific task, then you don't need to do design. You can be clever or not clever, but what you're doing is building a flexible solution. If you're designing a system, it necessarily operates in a domain (and/or creates it's own), and DDD is one of the best tools for trying to building language and feeling out where abstraction can/should be.
What the author seems to be wary of (which I agree with) is the cargo cult and legion of consultants pushing it. This article is essentially "use the right tool for the job, it's not always DDD", and I agree with the premise... but DDD is amazing when it's done well you can build systems that are easy to understand, manipulate and extend.
I’ve understood DDD to essentially be “focus on the business and here are some helpers that might make you more effective in doing so.” Do others find it overly prescriptive?
Which is basically true.
But as soon as you go more complex, you'll probably wish you'd used DDD from the start.
DDD is gaining traction, not because it's good. But because it's compatible with microservices.
As an aside, i also like how jgobard developped ContosoUniversity ( https://github.com/jbogard/ContosoUniversityDotNetCore / https://github.com/jbogard/ContosoUniversity/tree/master/src... ) with vertical slices and feature folders.
Perhaps the difficulty tho is that DDD in particular is a collection of ideas that I would opine might have quite different profiles in terms of both their applicability, and range of design scope. Ubiquitous Naming seems like its pretty widely applicable, and by its very nature is about building consensus within teams, whereas Repository, Factory, Service, Aggregate feel like they could be the dishes served up at some Object Oriented dinner party where the guests could quite justifiably argue long into the night about what the best model design should be.
DDD is a way of modelling your business logic. Your domain doesn’t care about databases or servers, these are details at the edges of your application.
If your domain does need to care about the details of how it runs on servers and databases, then perhaps DDD is not the right tool for the job.
And if you don't know the problem - then don't start doing anything. If you don't understand yourself well enough and cannot isolate a logical model, than stop, too.
For me, that's both timeless wisdom, and nothing special.
I myself find DDD a pilar I don't want to work with anymore.
1. It's a specific version of Model-driven Architecture. And the idea is very close to Hexagonal Architecture, Clean Architecture
2. There are a lot of cases when it's not worth it. If you don't have the vision to evolve your system for more than 3 years just forget about it.
3. Strategic design is more important than tactical design. You can adopt the former without the latter. If you only adopt the latter it doesn't help.
4. You don't have to adopt Microservice combined with DDD.
5. Start with coarse-grained Bounded Contexts if you're not experienced. Incorrectly fine-grained Bounded Context is simply painful.
The Good:
1. Ubiquitous languages. Even if you're not doing DDD it's a very good idea to keep in mind.
2. Strategic design. Microservices usually creates more problems than it solves, the idea of splitting Bounded Contexts helps to ease some pain of building Microservices.
3. The Aggregate. If you're doing tactical design, pay most attention to the Aggregate design.
The Bad:
1. Tactical design, the jargons like the Repositories, Domain Service, etc. IMO It's better to do the strategic stuff only, draw the Bounded Context, and let the autonomous teams do the implementation and forget the tactical stuff. They'll be motivated, feel fulfilled, and willing to improve the architecture of the fraction for themselves. In contrast to the Wizard vs Grunts (the Model Scientist vs Implementation Engineers) relations that are often seen in the financial industry.
2. The tactical jargons IMO are transient. They'll probably be starting to die out in a decade, just like most of the patterns described in the 'Patterns of Enterprise Application Architecture' from Martin Fowler.
The Ugly:
1. Don't expect you'll build models that aren't leaky. For example, your seemingly perfect model will still include tech infrastructures like Stream<User> or Flux<User>, unless you are using advanced languages like Scala and can parametrize them as TMonad<User>
2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model - if you're doing a traditional HTTP request/response Web project, your model will likely be a request/response one. If you think you're dreaming that you can use the same model for a real-time WebSocket project, or even a conflict-free collaborative project, good luck. You can build a real-time model in the first place, but it would be much more expensive.
3. The Repository pattern and the Aggregate pattern are like a trade-off to each other. The Aggregate wants to be rich and contain more domain logic, while the Repository stops them from being rich. As a comparison, the Active Record is much easier to be rich compared to the Repository, but it defeats the goal of being infrastructure agnostic. So if you're convinced you're going to do Web-only you can switch to Active Record + Aggregate rather than Repository. Just like 'Rails IS your application' according to DHH.
I'm a Scala dev and I know monads, but what exactly is TMonad<User>? Like `[T: Monad](users: T[Users])`?
> 2. Although it claims to help you to build pure models, the platform you're targeting will most likely still decide your model
I think that is a crucial point. In fact, the platform _is_ very often part of the domain and should be part of the language in DDD. It's one of the reasons why no-code solutions fail and why there is often a mismatch between developers and product-team - the latter does not see these things as part of the domain, but they are and if you don't describe them as it, there quickly is a mismatch between dreams and reality.
Pretty much like it. There's a popular pattern called Tagless Final which lets you parametrize it and then swap the implementation in the last step.
In this way the model layer wouldn't know the underlying implementation is Future, Promise, or Flux. Sometimes it's useful because the developer finds it's painful to migrate from libraries to libraries.
For example, from a domain driven point of view Awk operates on a simple structural hierarchy of input and output files, lines and fields; designing a nice DSL around the obvious operations on these entities is clearly a much greater achievement than designing (or rather postulating) this model.