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?

Question

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.

Answer 1

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

Answer 2

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