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.

  • 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
    Commented Jul 12, 2017 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
    Commented Jul 12, 2017 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
    Commented Jul 12, 2017 at 15:09
  • 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
    Commented Jul 13, 2017 at 5:33
  • 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
    Commented Sep 25, 2020 at 13:37

2 Answers 2


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.

  • 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
    Commented Jul 12, 2017 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. Commented Jul 12, 2017 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
    Commented Jul 12, 2017 at 15:20
  • 3
    @RobertHarvey: "Which really puts me at odds with the factory factory factory people.": Amen, brother.
    – Machado
    Commented Jul 12, 2017 at 15:29
  • 2
    Is it just a coindence this answer reminds me to the Ferengi's Rules of Acquisition? 8-)
    – Doc Brown
    Commented Jul 12, 2017 at 16:30

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

  • Can you recommend any books or articles on how to do the procedure style of coding well?
    – bdsl
    Commented Jul 22, 2021 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
    Commented Jul 26, 2021 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
    Commented Jul 26, 2021 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
    Commented Jul 26, 2021 at 13:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.