Code is data and any data that specifies business processes and defines their outcome is code.

If you can't iterate on the specification of business at the speed business itself needs to change, that's a problem, but it's a process problem, not something inherent in specifying business process in code.

Configuration

Configuration is still code, but maybe in a non-Turing-complete language (but maybe not, depending on where we are in the cycle of configuration fashions at the moment.)

Been wondering the same since I came across DDD while reading Team Topologies. I’ve heard similar feedback on the original book, and my search led me to a recent O’Reilly book:

Learning Domain-Driven Design, by Vlad Khononov

It’s 340 pages and has good reviews on Amazon etc, but I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.

> I’d be especially interested in feedback from anyone within a good understanding of the topic who’s read the O’Reilly book.

You're winter project is constructing a 3000 word amazon review on the book that will amass 500 likes across the next 20 years. you can look back on it when you retire and smile.

The attached article is great.

Does anyone have any experience or info on how to bring our Business logic out from domain classes and structures, into configuration?

Any examples or sample code?

As much as possible, build horizontal, functionality based services. As much as possible, avoid coding anything business specific into your core. Avoid product names, role names, user types, etc, in your code, databases, classes, files, APIs, services, etc. Create systems where those things can be entered as data, so configuration can be provisioned and updated by end users. Push the "domain" as far into user-land as you can (users entering data and configuration). Imagine how bad and inflexible bug tracker software would be if there were "product manager" and "software engineer" domains and services. Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain. That's why he argues Excel is so successful, there is no core domain nonsense, it's a functional piece of software that users can use to create whatever domain they want. As much as possible, avoid Domain Driven Design, except for the minimal useful parts (like using the same name for things in the same context).

I don't believe in this: if you follow through on that, you will end up with a low-code or no-code platform. Or basically, you are creating a programmable platform where your "configuration" is actually gonna be code.

When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes.

Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to.

If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad.

And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code.

> Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain.

I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution.

Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.

There’s a downside to this as well though.

You end up trying to debug/understand logic that slips through your hands like wisps of smoke.

It’s a trade off, just realize you are building a system that’s harder to reason about and add more observability and/or an ability to interact with the live system.

I think its required reading for inheriting large legacy codebases from the early 2000s written in Java; all the insanity suddenly makes sense

What’s the copyright law on taking ideas and principals from a book like that, and rewriting it?

Someone correct me if I'm wrong, but it seems like it should be fine. Copyright applies to specific concrete representations and not things like abstract underlying ideas.

Yes. It applies to what you do / make. You can’t copy (parts of) the written text, but you can act (write your own interpretation) with the ideas in that text.

“Copyright is intended to protect the original expression of an idea in the form of a creative work, but not the idea itself.”

https://en.m.wikipedia.org/wiki/Copyright

I always found it ironic that a book that advocates concise documentation and diagrams over text looses itself in way too much narrative.