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

121–130 of 198 posts

Re: Domain-Driven Design

#121

Post by jeltz »

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.

Re: Domain-Driven Design

#122

Post by ratww »

mnsc wrote: post #80
sweezyjeezy wrote: post #77

Earlier quoted context omitted.

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

Ok, so in practice you are saying that no good programming paradigm exists. Where do we go from there?

Well, I don't think anything changed. We already knew there was no Silver Bullet.

To paraphrase Brooks, no pattern or methodology is gonna make development "more productive, more reliable or simpler". All patterns and methodologies require a skilled practitioner, but someone skilled enough can even eschew them and still make good software, so in the end they don't really matter.

The point of patterns/methodologies is purely to facilitate communication between experts, not to guide.

In the end, good software is not about following recipes, especially complex recipes. It's a craft.

As for where do we go, what we need is the foundation for personally re-discovering and internalising those same methodologies and patterns, rather than blindly following them. Sweezyjeezy already enumerated some ideas above, and I have done the same in the past: https://news.ycombinator.com/item?id=27987498

Re: Domain-Driven Design

#123

Post by necovek »

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 closely related), to keep the abstraction creep at bay and apply only meaningful abstractions. And others are simply not interested enough, and they know they can get a LGTM with following misjudged patterns.

They also jump at the opportunity to use identical terms from the DDD book, and then keep explaining them with more colloquial terms everybody understands: it'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?

I get the argument that a new language allows for consistency, but it still gets misapplied, because it's the same humans doing the work.

I can't think of a better parallel than SQL-vs-noSQL databases: sure, no-ACID makes a bunch of things simpler, but then every developer has to think through all of the same problems ACID DBs solve, and majority will get them wrong (or maybe even everybody would get them wrong _most of the time_).

Re: Domain-Driven Design

#124

Post by berkes »

MihaiSandor wrote: post #9
Fiahil wrote: post #6

I attended a few DDD meetup a few years ago, and it never quite made sense why would you engage in this kind of architecture nowadays. The room was filled with experienced Java developers with deep Enterprise Software(tm) knowledge. Then, I started working as an AI Software Engineer (mix of a software engineer + devops + data scientist), and it all clicked. DDD is a wonderful design pattern for anything related to Da…

And the most important thing is that you have clear benefits in communication using a common domain language.

I need to second this.

The ubiquitous language alone, is highly valuable.

Even if you dislike the ideas about software architecture that DDD introduces, having a clear, broadly carried, living dictionary, helps a lot! No more EntityTreeSectionBatchBuilder, but CompanyDivisionBuilder. No more 'yea, the ActorModel is really what should have been the User, but since User has legacy in the Authentication part (which also does some authorization, it's on the backlog), we needed another model name.

But also, learning about your domain, writing that down, outside (or before) patterns, frameworks, libraries start enforcing their domain, is very liberating and valuable in the long run.

Re: Domain-Driven Design

#125

Post by ratww »

afurculita wrote: post #74
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…

You don't use DDD at your current company. Naming it DDD doesn't make it DDD.

That's the "No True Yorkshireman" fallacy.

In my experience it's extremely safe to assume that, even with the best intentions, DDD code can become stupid big balls of mud.

Re: Domain-Driven Design

#126

Post by gibsonf1 »

This principle is a key flaw in the idea: "A complex domain can not be efficiently expressed as a single universal model and language, and must therefore be separated into Bounded Contexts (ie. an internally consistent language and model) by the system designers". We humans understand how everything we experience is part of a wider world. So if you are unable to know how things relate, as all things do, you do not yet understand the domain.

Re: Domain-Driven Design

#127

Post by Roonerelli »

ToJans wrote: post #23
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…

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…

I attended the Domain Driven Design Exchange conference in London years ago. They keynote was by Eric Evans (author of the DDD Blue Book)

He said if he wrote the book again, he'd have put all the patterns as an appendix

He thought people concentrate on applying the patterns rather than seeing DDD as a way to communicate. Between developers but also to the business

Re: Domain-Driven Design

#129

Post by berkes »

mhd wrote: post #38
dm3 wrote: post #14

Earlier quoted context omitted.

Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations. ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.

I've seen architecture presentation where it seemed like event sourcing took DDD hostage, just using it as a vehicle to sell that particular astronaut-ism. Not even a ubiquitous language...

I think part of the reason is that event-sourced needs DDD. So any story or presentation about ES, will at least mention DDD.

But DDD, by no means, needs ES.

Another part of the reason, I think, is because many other architectural patterns have taken certain concepts 'hostage'. Take for example Rails. MVC. 'Model' in Rails has a clear and distinct meaning, place and implementation. There is no way to have a bounded context, isolated domain models in Rails, without at least the terminology becoming very confusing. Having root aggregates in Rails makes all that worse, even.

What I'm trying to paint, here, is that ES naturally embraces DDD, whereas other architectures often conflict, or require effort to fit in DDD. Therefore, you'll probably find many talks about ES or CQRS and DDD, but hardly any about Actor, MVC, etc., and DDD.

Re: Domain-Driven Design

#130

Post by jasonhansel »

DDD is a wonderful idea and one that I think should be applied more broadly: a deep understanding of the problem domain, shared between tech and product, can greatly improve quality, reduce bugs, simplify communication, and even result in better structured code. In particular, it tends to lead to code structure that follows the structure of the underlying problem domain, which tends to be much clearer than code that just tries to implement features without an underlying understanding of their purpose.

The design patterns and actual implementations traditionally associated with DDD, on the other hand, are quite bad, and tend to lead to Enterprise Software levels of cruft and/or excessively dogmatic use of OOP.

Post reply on HN