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

DDD Is Overrated

tilkov.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: DDD Is Overrated

#31

Post by notretarded »

sfvisser wrote: post #29

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…

But you only know that through experience of developing against said practices...

Re: DDD Is Overrated

#32

Post by LudwigNagasena »

rtpg wrote: post #3

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

I have read similar thoughts on psychology. Makes sense to me.

Re: DDD Is Overrated

#33

Post by mixmastamyk »

linsomniac wrote: post #2

Maybe update the title to "Domain Driven Design is Overrated", because this article has nothing to do with the Data Display Debugger.

I was thinking of a fully digital audio recording, digital mixing, and digital mastering. :-)

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

Re: DDD Is Overrated

#34

Post by Jach »

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

Re: DDD Is Overrated

#35

Post by stepbeek »

stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i 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…

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.

Re: DDD Is Overrated

#36

Post by idiocratic »

stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i 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…

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.

Re: DDD Is Overrated

#38

Post by xupybd »

stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i 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…

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.

Re: DDD Is Overrated

#39

Post by virgilp »

stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i 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…

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.

Re: DDD Is Overrated

#40

Post by xupybd »

stepbeek wrote: post #35
stevebmark wrote: post #19

Better article: https://dev.to/cheetah100/domain-driven-disaster-147i 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…

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.

Have you tried Scott Wlaschin's book. It's a very easy read.
Post reply on HN