16

From all I read and watch, Domain-Driven Design (DDD), is a costly and time-consuming endeavor. In fact, everyone I have seen, including Eric Evans and Greg Young, say, don't use DDD except where you have a "Competitive Advantage." To find that advantage it kind of drops off into various discussions of business and T-Shirts. That's fine. I understand that's a business decision, not necessarily DDD proper, though DDD helps identify it.

What does a company do with the non-Competitive aspects of their system that they simply cannot buy off-the-shelf software for?

For example, an inventory program. Lots of companies have inventory programs. Most of them have the same features. It's marketing that separates most of them and reputation. For DDD, I don't know these all have any Competitive Advantage.

Where does DDD fit into these scenarios? I'd really like to use DDD because I like its principles, but I am finding it makes little sense, at least for me, given the caveats of the proponents.

So, I am right back where I started with other design methodologies (not that they are bad.) And, I use the word "methodologies" loosely because DDD is more about principles, as so many "methods" are. I can only take principles here (Ubiquitous language and so on), but not much else.

What do I use as an alternative to Domain-Driven Design, if I cannot define a Competitive-Advantage area of my system to apply it? Should I use DDD anyway? Doesn't seem like it.

What I really don't get is when does someone not use an analyst or the like to understand a business. How else would the developers know what to write? That's not DDD; that's just common sense.

Not asking about tactics here, but rather strategy (as some I have read word it.)

Example from Vaughn Vernon, https://vaughnvernon.co/?p=879

Speaking about the Entity Framework and DDD, "Just allow Entity Framework to map entities and get back to what will make a difference in this competitive world: your market-distinguishing application."

It seems like DDD is not for 90% of the world, only the Magic Quadrant.

xhafan
  • 103
  • 4
johnny
  • 3,669
  • 3
  • 21
  • 35
  • It depends. Take your example of inventory programs. Most companies use them to track inventories of course. In fact they're so mundane most e-commerce platforms have them built in. But Amazon took that aspect of it and turned it into their Competitive Advantage. Amazon's inventory program now control robots and even contain height of employees so that the program does not send short employees to fetch items in high shelves. Take another example: servers. Servers are commodity but Amazon turned servers into their Competitive Advantage. – slebetman Jul 12 '17 at 15:06
  • The real question is what aspect of the business can you afford to build out and design properly RIGHT NOW, and what would you simply buy instead. Personally after Amazon and Google I don't see any reason why any company would spend time to figure out how to properly build a server farm. I'd rather just do what Netflix does and just buy instances. So it depends on what you can afford to work on and what is available in the market – slebetman Jul 12 '17 at 15:08
  • 1
    But there are some companies that make a lot of money with their "regular" product, inventory. They do good marketing and all the rest, but the advantage is not some special inventory software feature. – johnny Jul 12 '17 at 15:09
  • Again it depends. You have to balance the business, not the technology. Tech does not matter, business decisions come first. Once the business concerns are met your job as the tech implementer is to execute the decisions. And business decisions are what determines what a business would like to be their Competitive Advantage. Sometimes you are invited to the discussion table, sometimes not. – slebetman Jul 12 '17 at 15:11
  • @slebetman Seems to me most people are doing DDD because it is what the "Cool Kids" do, and I don't mean the people like Eric Evans. I mean hype. – johnny Jul 12 '17 at 15:14
  • 1
    Well, DDD as you mentioned is just the new hype to an old thing - programmers SHOULD understand what they're writing in order to not produce buggy code. I mean, if you don't understand color theory how on earth would you even begin to write Adobe Photoshop? (the Knoll brothers understood color theory which allowed them to write Adobe Photoshop). We've been doing what DDD proposes since the days of Alan Turing at Bletchley Park – slebetman Jul 13 '17 at 05:33
  • All I can figure is the big boys only deal with top 100 companies that have the competitive advantage and they sell books and conference seats. – johnny Jul 13 '17 at 16:31
  • 1
    @johny you hit the right points esp "How else would the developers know what to write? That's not DDD; that's just common sense.". Whenever I read DDD is about "focus on business problem", wonder isn't that universally true, whether DDD or not? That still stays unanswered here. – Amit Sep 25 '20 at 13:37

2 Answers2

21

Here are some rules that I have come up with to help:

The Rule of Requisition:

Use a tool/technique/principle only when the benefits exceed the costs.*

Note that "competitive advantage" is not the only criteria. There are many others.

Here's another one.. The Rule of Replenishment, which reads:

You don't necessarily have to drink the entire jug of Kool-aid.

Sometimes you just need one tool out of the entire toolkit. In the case of DDD, many developers could benefit solely from the concept of an "ubiquitous language," having neither learned nor utilized any of the other tools.

And finally, The Law of Best Practices:

There is no such thing as a "best practice." There is only that which most effectively meets your specific requirements.

and The Law of Scale:

Don't use a jackhammer when a ball peen hammer will suffice.

* There are always costs.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
  • 1
    Thanks. I drink lots of different flavors, but am a purist, so I have to remember i can drink some of the jug. Academics vs. Real-World I think. I started searching for Robert's Rule of Requisition and then, oh wait, he's Robert :). – johnny Jul 12 '17 at 15:13
  • 12
    I think I am a minimalist. Robert's Law of Minimalism says *"All other things being equal, less code is always better."* Which really puts me at odds with the factory factory factory people. – Robert Harvey Jul 12 '17 at 15:18
  • 1
    Well, I look at lots of design and think, why the heck are they abstracting the abstraction? It make no sense, even with understanding Spolsky's Architect Astronaut. I think about 85% of what I see are people that have no real idea why they are doing what they are doing even though what they are doing works. I grow weary of it. – johnny Jul 12 '17 at 15:20
  • Most enterprise-level abstraction serves but one purpose: to provide divide-and-conquer organization, separation of concerns and manageable compartments of code for large software development teams. It's code that only belongs in large, enterprise applications, the top 5% in size and scope. I suspect it's used far beyond that 5%. – Robert Harvey Jul 12 '17 at 15:26
  • 3
    @RobertHarvey: "*Which really puts me at odds with the factory factory factory people.*": Amen, brother. – Machado Jul 12 '17 at 15:29
  • @RobertHarvey Do you have any example questions or answers that shows the factory factory factory people? I'd love to read what you say. – johnny Jul 12 '17 at 15:33
  • See [Execution in the Kingdom of Nouns.](http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html) The folks who are committed to all that ceremony are seldom swayed by people like me. – Robert Harvey Jul 12 '17 at 15:36
  • In all fairness, some people need a track to follow. "Put that there." – Robert Harvey Jul 12 '17 at 15:48
  • 2
    Is it just a coindence this answer reminds me to the Ferengi's [Rules of Acquisition](http://memory-alpha.wikia.com/wiki/Rules_of_Acquisition)? 8-) – Doc Brown Jul 12 '17 at 16:30
  • @DocBrown Not a coincidence. – Robert Harvey Jul 12 '17 at 16:33
  • That is great. I haven't thought about the Ferengi in a while. I do wonder if Harcourt Mudd would agree, however (in principle). I just don't want to end up like the Pakleds (in principle). – johnny Jul 12 '17 at 16:43
6

In the Red book (implementing DDD), there is DDD scorecard at page 11, which helps you recognize when DDD should be considered.

for example

  • If your project contains 30+ user stories
  • will grow in complexity
  • application's features are going to change often
  • the domain is new and you and your team does not understand the domain

that means, more complex and changing the domain is, the more benefit DDD will bring. The lightweight alternative is probably procedure style of coding (business logic inside database stored procedures or inside controller actions).

Muflix
  • 195
  • 2
  • 8
  • Can you recommend any books or articles on how to do the procedure style of coding well? – bdsl Jul 22 '21 at 22:31
  • @bdsl I do not recommend to use stored procedures because I realized it is hard to test since you have to use real database, but I recommend to use ORM (without encapsulation its called an anemic model and it is an anti pattern but it is a good start). – Muflix Jul 26 '21 at 13:48
  • @bdsl If you don't want to encapsulate domain logic inside entities you can put logic directly inside controllers (but only if the logic is trivial, otherwise you will end up with fat controllers which is also an anti pattern). – Muflix Jul 26 '21 at 13:49
  • @bdsl You can also put non-trivial logic from the controller into the command-handler. Controller is responsible for HTTP request handling and CommandHandler will be responsible for the operation itself, so you will split the responsibilities and therefore reduce complexity. – Muflix Jul 26 '21 at 13:52