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

171–180 of 198 posts

Re: Domain-Driven Design

#171

Post by Kototama »

necovek wrote: post #123

Like the original post fails to mention any stakeholders when it comes to developing "Ubiquitous Language" (it enumerates "engineers, testers, analysts, …", and I don't think ellipses does any justice to them), most people forget that DDD is about modelling the real world before you start coding. My experience is that, unfortunately, majority of developers are either not experienced enough, or smart enough (these are…

> 's like social sciences all over again (sorry social sciences, but it's what it is) where they invent terms so they'd be more "scientific". Why not simply use the terms everybody understands?

To be precise probably. Every domain develops a jargon at some point. It can be used to exclude or sound smart but most of the time it just to be precise. Common terms are too much vague / polysemic.

Why do you need words like compiler, linker, dynamic and static types and linter instead of using common words?

Re: Domain-Driven Design

#172

Post by alex_zim »

As anything else, a blind application of a technique, paradigm, or pattern, could be horrific. It doesn't matter what combination of capital letters is used. I've done horrific things when I was "doing DDD", until I realised how simple and elegant domain models could be when done right. Forcing people to do something they aren't used to and expect decent results is disastrous in any industry. It's just in software everything can be "refactored" so we are more easy-going with those things.

With DDD "done right" there's no issue with understanding what the code does because it's split into tons of files. It's actually the opposite. But, indeed, it could be a nightmare when applied blindly, or forcibly because of some ivory-tower architect decided to "use DDD" without even knowing what it is. I know as I've been that guy.

Re: Domain-Driven Design

#173

Post by pjmorris »

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…

> instead of pondering the question, do you really need to rewrite everything following DDD?

Anecdotal: I chatted with Eric Evans, author of the DDD book, at a conference once, and he stressed that DDD was only appropriate for certain parts of the system that called for it. I think he'd be as frustrated as you are by the situation you describe.

Re: Domain-Driven Design

#174

Post by amw-zero »

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

Earlier quoted context omitted.

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

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

What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good reasons?

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

This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context?

It's like, building any system involving many actors and actions is hard, that has nothing to do with software. We're just digitizing the same patterns and behaviors that people have used to run companies for hundreds of years.

People want a playbook to be followed to arrive at a "perfect" domain model or architecture. I'm sorry, that sounds pretty farfetched to me. It reminds me of how we first started thinking about computability theory, when David Hilbert proposed that we should be able to devise an algorithm that could decide the truth or falsity of any logical statement (the Entscheidungsproblem). Hilbert was one of the smartest mathematicians to ever live, and he was very confident that this could be done.

Well, Alan Turing, Kurt Gödel, and Alonzo Church (not slouches in their own right) all smashed that idea with various proofs. The truth can often be counterintuitive. I am sorry that the world is complex, I also wish it weren't so.

Re: Domain-Driven Design

#175

Post by corpMaverick »

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…

Parent poster also mentions in another post that they are also using Microservices.

I can see how excessive detail division into Microservices can create a nightmare. I have seen it over and over. We need better guidance on how to breakdown services and how much. Erik Evans touches on this https://www.youtube.com/watch?v=sFCgXH7DwxM but I still think he is to shy on giving advice. Microservices are valuable because they allow your team to work autonomously. So you you should roughly have one Microservice per team. It is not a hard rule at all, but it can help to see if your microservices are too granular. That is the number of Microservices should be about 5 to 7 times larger than the number of developers. If you have less than 2 developers per Microservice, you are probably creating a maintenance nightmare.

Re: Domain-Driven Design

#176

Post by corpMaverick »

amw-zero wrote: post #174
pydry wrote: post #162

Earlier quoted context omitted.

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

> Try to mininimize the overlap between bounded contexts - loosely coupling domain models. What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good reasons? > Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts This is exactly the ambiguous advice that you are rallyi…

> This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context?

This is a very important question. I will bite and give a guidance because no one is willing to give advice here. If you development team grows over 10 SE. Then you need to split it. So your bounded context has a complete team on it becoming experts in the subject as well as experts in the software implementation. Each team should be able to work independently of other teams.

Re: Domain-Driven Design

#177

Post by zerkten »

afarrell wrote: post #61
ToJans wrote: post #23

Earlier quoted context omitted.

Tactical/technical DDD patterns should only be used for parts of the code where there is a lot of business agility required, so the behavior of your code changes a lot, and you have a tight feedback loop with your business unit. Your story sounds like they implemented a "technical DDD top-level architecture" (TM), whatever that may be. (I'd assume layers of abstractions coupled with logic spread all over the place, w…

Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company? Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?

> Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company?

To get buy-in you have to provide value for them that aligns with their needs. If they desire a delusional feeling of outsized importance within an organization then you need to be quite creative. It's more likely that their needs are simpler though. They need to feel they are getting value from you, even if the other parts of the business hold more of the cards.

Try to find simple things to fix for them, choose to build out features with their input, and when building new features for the main stakeholders try and prioritize items which help multiple stakeholders. This is good practice in any case because in the long-term things can change quite significantly within organizations and you don't want to be perceived as only an ally of some within the business.

UPDATE: Beware of quantifying too much. This really impresses some people but will make others feel really small. You may completely lose a connection with one of the smaller stakeholders by quantifying every detail and calling out big numbers around the large stakeholders. You need to work qualitatively for the most part for them. If you want to use numbers, pilot something with a small stakeholder and make a 25% increase to their sales (or a cost reduction). If big holders can get a similar percentage then that translates to big numbers. It feels like a big number to both groups.

Re: Domain-Driven Design

#178

Post by hiram112 »

kqr wrote: post #147
afarrell wrote: post #61

Earlier quoted context omitted.

Any tips on to persuade a stakeholder , senior leader, or your team lead that their area of focus is not a core part of the business without them feeling defensive about their status within the company? Any tips of how to do DDD when every area is considered a core priority of the business because uncomfortable conversations are hard?

Frame it in terms of money. "There is some benefits to what you're proposing. My primary concern is cost. I see no technical difficulties with doing it , and one of the benefits of that is that you'd have it ready in a tenth of the time. If I'm wrong, we can always change our minds and build it your way. That would barely take any additional time at all, since what I'm proposing is so simple to begin with. "So, what…

> "So, what do you say? Would you like to try to get it done by November, or should we labour over it until next June? If I understand the business figures right, if we can get it out in November, we'll make $6,000,000 more – and it would all be because you made the right technical decision here."

...

"We were able to get this out by end of November, thanks to your good technical decision. $6,000,000 saved! Congrats and great job. Accordingly, you've qualified for an annual bonus of a $100 Amazon Gift Card and the default 1.5% raise.

Keep up the good work!"

Re: Domain-Driven Design

#179

Post by sigzero »

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…

I've been in a similar situation so I hear you. It is so mentally draining.

Re: Domain-Driven Design

#180

Post by amw-zero »

corpMaverick wrote: post #176
amw-zero wrote: post #174

Earlier quoted context omitted.

> Try to mininimize the overlap between bounded contexts - loosely coupling domain models. What if this doesn't lead to a more accurate representation of the domain? What if two contexts are just coupled in the business, for good reasons? > Default to "too large" to begin with and institute a pattern for breaking down a bounded context into two smaller contexts This is exactly the ambiguous advice that you are rallyi…

> This is exactly the ambiguous advice that you are rallying against. How do you know when to break down a context? This is a very important question. I will bite and give a guidance because no one is willing to give advice here. If you development team grows over 10 SE. Then you need to split it. So your bounded context has a complete team on it becoming experts in the subject as well as experts in the software impl…

Forming your bounded contexts based on technical complexity and team configuration is certainly not advocated by DDD.

Is "larger than 10 software engineers" a rule that domain experts would suggest? Would that be in the ubiquitous language?

Post reply on HN