Engineering is like 50% about what you actively choose to not do, 40% making sure nobody else does it, and 10% doing it.

Thanks for sharing the article! The idea of making a framework for executing business logic that can be dynamically defined by users is old. It is realised in rule engines, embedded scripting, DSLs.

As usually, no silver bullet, but a good solution for right cases. Domain experts are given a tool to express and run the domain logic with different grades of flexibility without reliance on software engineers for coding and deployment. In theory.

Now the domain is expressed in both the tool and user configs. It may be difficult to find the right balance between flexibility and pushing complexity on end users and their configs. There is a real risk to make wrong choices here.

Another issue is that the more flexibility the tool provides is the stronger is the need across domain experts to manage the changes in business logic: review, rollback, logs - basically you want to have mini-Git and proto-CI/CD.

Also, the tool itself can require complex installation and maintenance. It will definitely be more resources-hungry comparing to a similar hardcoded solution - it is a payment for flexibility. The tool can scale, if it was a design decision - think about resource allocation in Apache Spark, Mesos, kubernetes.

Do not forget that now users need to learn your tool - I think teaching advanced Excel courses provides food on the table for many people.

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.

If the flaw of DDD is that there is no emphasis on when not to use it, then the flaw of Peter's article is that, according to him, you should never use it ("software should be designed around function rather than domain").

I agree with his point that DDD will restrict an application that could be generic to a specific domain. When you can build something generic you should. But not everything can be made that way.

Also: "someone who should not communicate with humans" is a little bit too much.

You make some valid points, but “good ideas written by someone who should not communicate with humans” - a bit harsh don’t you think?

After reading all 500 grueling pages of DDD, that could have been 50 pages, no, I do not regret my hyperbole.

I do think it’s harsh that Eric Evans charges up to $4,000 a head for DDD workshops.

Here you go : https://www.infoq.com/minibooks/domain-driven-design-quickly... ~100pages

Here a smaller one: https://github.com/engma/ddd-inanutshell

At least it was hyperbole, thanks fir the clarification.

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.

I haven't, is this the one? https://www.amazon.co.uk/Domain-Modeling-Made-Functional-Dom...

That is the one. It's also an introduction to structuring an F# application so it might not be for everyone but it's an easy read.

Also I'd recommend getting it from here. https://pragprog.com/titles/swdddf/domain-modeling-made-func...

Just because I personally like the pragprog site.

I’ll give it a shot - I’ve done some FP so I’m not put off by F#.

Thanks!

I found his Effective Aggregate Design pdfs very helpful https://www.dddcommunity.org/library/vernon_2011/, in addition to the DDD quickly book on Infoq, and Functional and Reactive Domain Modeling by Debasish Ghosh https://www.manning.com/books/functional-and-reactive-domain...

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.

> The biggest flaw of DDD I've run into is there's no emphasis on when not to use it

Except that there's literally an entire chapter in the book on Generic Subdomains. It says to move everything that is not the critical motivation for the project out of the core, give it lower prio, put junior devs on it, or outsource it entirely.

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.

To elaborate —

Domain driven design is about understanding the business requirements enough to know “this is fundamental to the domain” versus “this is going to change next month”.

In the accounting example, when you talk to the accountants and develop an ubiquitous language, you’ll notice that long term concepts are “assets”, “transactions”, “taxes”, etc. while the transient things are exact tax rates, how transactions are structured (eg, net 30), etc.

So you’d build your system to match:

- A foundation of transacting assets/currency/inventory

- A system for defining transaction flows

- A system for reporting transaction aggregates (eg, for tax filings)

Domain driven design doesn’t say which of those to hardcode versus make user configurable — it says to talk to your users until you understand the domain, then build software that reflects that.

Like most good ideas, people get way too formulaic about it sometimes.

Interesting to see all of the discussion on hard-coding vs configuring domain/business logic, when in reality most line-of-business app developers are never introduced to the very concept of business/domain logic, and therefore it gets strewn all throughout an application’s code based, tangled in with data retrieval, u/i concerns, and everything else.

Yes — the goal of DDD is to explain why that’s a bad idea. For two reasons.

1. It makes your code a mess.

2. You probably wrote the wrong thing anyway, because how do you know what the customer wants if you don’t even know what they do?

DDD argues you should develop software by:

1. Talking to customers about the domain until you have a shared language with specific terminology.

2. Write that down as a model.

3. Write that model as software.

I think one of the biggest misses in software engineering (and something I’ve seen cost $100Ms) is software developers not talking to customers about what they do with the software. Some of the worst bugs happen because domain experts mean something by a term of art that software developers misunderstand.

DDD overlaps heavily with the “applied category theory” perspective on software, so DDD tends to be popular with functional programming types.

This is literally why Fowler and Evans wrote their books, some of this "tangling" was viewed as a feature because it let a single dev own an issue and avoided the bottleneck of architecture by committee.