Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Domain-Driven Design

verraes.net

Post reply on HN
Print view View original

161–170 of 198 posts

Re: Domain-Driven Design

#161

Post by myth2018 »

sweezyjeezy wrote: post #77
oscarcp wrote: post #17

We use DDD at the current company I work in and to be honest, I detest it so much that sometimes it makes me wonder if I even want to continue in the programming space (been at it for 20 years). Don't get me wrong, DDD has meaning and purpose, but some companies are applying it as a badge to be obtained instead of pondering the question, do you really need to rewrite everything following DDD? In our case, simple CRUD…

> Now, you could make the argument "You Are Doing It Wrong(tm)" I always hate these arguments - for me, whether a particular programming paradigm is 'good' or 'bad' for an organisation comes down to: "what will my least senior developer do with this?". If it tends to produce tangled nightmares, then it's not a good paradigm, it's about how the weakest link will use it, not the strongest ones.

> for me, whether a particular programming paradigm is 'good' or 'bad' for an organisation comes down to: "what will my least senior developer do with this?"

I wish ideas like these were more prevalent or that, at least, people considered that in many cases the quality of a method or practice is not an intrinsic attribute, but a matter of suitability to a particular environment.

That's the problem I have with agile enthusiasts in general. I've seen agile methods operating wonders on many projects, but I've seen it failing on much more, and it's completely OK to assume that the method has its assumptions/conditions/limitations but enthusiasts, instead, blame the company and practitioners for not having understood and applied it appropriately.

Re: Domain-Driven Design

#162

Post by pydry »

amw-zero wrote: post #155
pydry wrote: post #27

Earlier quoted context omitted.

I noticed something similar. A minimal PR to introduce DDD on our code base ballooned the codebase by something like 1,000 lines, smattered all over the code base. I think it would have ballooned it by about 12-15,000 in total in the end if we'd used it everywhere. That would have been fertile breeding ground for bugs. The ideas made sense on logically complex code that required frequent refactoring, but the strict s…

If there were a way to produce bounded context boundaries by following a general pattern / algorithm, what would that be? I fail to see how they can be created usefully without lot's of conversations with domain experts plus elbow grease. It's the part of software that remains entirely art and not science. Why is that a bad thing?

My impression was that it would:

* Try to mininimize the overlap between bounded contexts - loosely coupling domain models.

* Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts.

I tend to find any process that defaults to "have more conversations/interactions" defaults to wheel spinning without some sort of specific plan about what those interactions would entail.

Re: Domain-Driven Design

#163

Post by LennyWhiteJr »

Seeing a lot of hate for DDD here so let me offer an alternative point of view from someone who advocated for DDD on my team.

When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler

- There was a 'domain model' in the loosest possible sense - Each model type was just a POJO with raw getters/setters for each field - Almost all fields were primitives (mostly strings with a few int/doubles/dates) - All validation code for these types was done in application code and was fragmented throughout the code base - Internal DB identifiers were fully exposed into the code model - Internal service types were liberally mixed with external service types - No notion of aggregate roots - every entity was just accessed ad-hoc

It was a highly unsustainable approach, and one of the first thing I did was attempt to implement strategic DDD in the areas that were the most painful. This included

- Adopting rich value objects to represent domain concepts instead of raw strings - Enforcing business invariants inside the model classes - Enriching the domain entities with methods that matched business behavior and performed validation - Creation of repositories that shifted much of the persistence details out of the application code - Defining aggregates based on our required access patterns which simplified our data access - Bounded contexts for our internal domain - mapping external service types to our own internal representation

The result of all this was the creation of a core 'domain model' that captured business behavior expected of our service and most importantly, ended up significantly simplifying the rest of the application code. If DDD makes your app code more complex, you're doing something wrong.

Re: Domain-Driven Design

#164

Post by dm3 »

ratww wrote: post #134
pydry wrote: post #95

Earlier quoted context omitted.

>Doesn't matter if your code has a type named `Aggregate` in it. Matters if you get your consistency boundaries right I tended to find a lot written about the former and very little written about the latter. In fact I found essentially zero practical or actionable advice about getting the boundaries right beyond just "it's important to get it right". DDD doesnt appear to have a coherent opinion beyond that. Not in th…

I've found that separating around "abstraction levels", to use Clean Code lingo, really helps for defining good boundaries. This is really super-emphasised in Clean Code, but I find this the most important concept in the book. Examples: Are you writing to disk? Printing to the screen? Saving to the database? This is a different "abstraction level" than your data processing, those things should be separated by a bound…

This is a bit different. You are talking about a domain where the developer is usually the domain expert. You know very well what "procedurally generated terrain", "3D renderer", "database", "screen" and "framebuffer" are. Even if you don't - good and unambiguous definitions are usually just a couple internet searches away.

Now imagine you need to encode behaviours for a system where domain experts use terms and jargon you've never heard before. Even worse, users of the same system coming from different departments use the same terms to mean different things. How do you draw the boundaries there? That's what the GP finds disappointing - there is no single guide or reliable process to jump into a new domain and get the boundaries right.

Re: Domain-Driven Design

#165

Post by lolinder »

jeltz wrote: post #121
seanwilson wrote: post #7

> Software for a complex domain requires all designers (engineers, testers, analysts, …) to have a deep, shared understanding of the domain, guided by domain experts ... That understanding is rooted in language: the domain language should be formalised into a Ubiquitous Language (shared, agreed upon, unambiguous) ... > DDD is not prescriptive. It doesn’t have rules of how to do it, and is open to new interpretation.…

Agreed, my issue wity DDD is that it is based on a bunch of good ideas but very little of it is actually actionable.

I actually think that this perception is what has caused most of the architectural overkill mentioned in this thread. People want something "actionable", so they extract the specific patterns.

The most important part of DDD is the principles. It's a way of looking at the world and at problems, of seeing things first and foremost from the business perspective. How you apply those principles to achieve that perspective must vary dramatically from project to project, which means that the details of action are left to you to decide.

Re: Domain-Driven Design

#166

Post by amw-zero »

pmontra wrote: post #18

I didn't read the PDF but it seems a way to formalize the usual analysis of customer requirements. It goes like this: 1. Understand the business of the customer, or any requirement won't make sense. 2. Learn the jargon of the business, or you won't be able to communicate. 3. Use that jargon when naming database tables, software modules, variables, everything, or you'll have to translate between your possibly abstract…

The post is just this web page. You just need to read the posted link.

Re: Domain-Driven Design

#167

Post by JohnWhigham »

kklisura wrote: post #87

Remember when people got offended by the "DDD" acronym? [1] "Good" times... [1] https://twitter.com/sarahmei/status/1073251153360482304

I just don't understand people that insist on bringing their emotional baggage into absolutely everything.

Re: Domain-Driven Design

#168

Post by stepbeek »

LennyWhiteJr wrote: post #163

Seeing a lot of hate for DDD here so let me offer an alternative point of view from someone who advocated for DDD on my team. When I joined, my team had been building the backend for the first version of our app for about 4 months. I would describe the state of the code base when I joined as an 'Anemic Domain Model' as defined by Martin Fowler - There was a 'domain model' in the loosest possible sense - Each model ty…

This sounds like another data point of many in this thread that point towards DDD as a philosophy working very well, while enforcing technical techniques advocated for in the book being hit-or-miss.

This makes intuitive sense to me: it’s much easier to define a principle that applies in many situations but much harder to define concrete technical implementations that do.

In your situation it sounds like the multiplier you applied was in pushing your team towards a rich domain. That’s a much more sensible approach than, say, using CQRS everywhere.

Re: Domain-Driven Design

#169

Post by amw-zero »

torginus wrote: post #31

I clicked this article to find out what DDD is as I've heard the term and was curious to learn more about it. Unfortunately, this article does very little to enlighten me besides the very basic common sense stuff, like understanding the business domain/keeping in close contact with the people who do. The above idea is hardly revolutionary anyway, I'm sure many people operated this way DDD or not. This seems like anot…

It may seem like common sense, but I have worked with many people who don't understand the importance of the actual software reflecting the domain that is being served. It's funny that DDD is criticized for being "too technical" when the whole point of it is that technical concerns must always serve the domain / customers, and that technology merely enables that.

And, conversely, I have seen many people get extremely excited about solving technical problems that aren't related to the underlying business in any way. That is why the book needed to be written - people are more concerned with the newest database or frontend framework, but have lost sight of the purpose of software: to provide value to people.

So, sure, there are DDD consultants and trainers. They're going to capitalize off of the idea like vultures, as is done with all ideas and movements. But, the core beliefs of DDD seem like a good idea to me.

Re: Domain-Driven Design

#170

Post by ratww »

endymi0n wrote: post #145
danielvaughn wrote: post #140

Earlier quoted context omitted.

I read a bit about DDD but never really went in-depth with it, like I never read the book or anything. Instead I just try to absorb the major takeaways that I got from what I've read: 1. Bring in people with domain knowledge to help you understand the expected behavior of the system. 2. Try to establish a consistent language that is used in both verbal conversations as well as code. I feel like those are good, easy-t…

This is exactly spot on and my go-to approach as well. I always thought myself of a huge fan of DDD, simply because I think it makes so much sense to discuss the architecture directly with the stakeholders until everyone technical and nontechnical alike really agrees about the existence, relation and constraints of entities: By using common, ubiquitous language and just giving the same things the same consistent, com…

Yep, exact same experience.

I also had the unfortunate experience of working with some die-hards who believe DDD dictates that "the code and only the code should reflect the business requirements 1:1", with emphasis on the "only". Which means that things that are often configurable in other systems are instead hardcoded and scattered in the codebase done by those. In early stage startups this is a death kneel.

Post reply on HN