5 ms·

"Domain Driven Design" is very poorly written. It's 500 pages of small print with small margins, so realistically it's closer to 750-1,000 pages. Evans is a ter

"Domain Driven Design" is very poorly written. It's 500 pages of small print with small margins, so realistically it's closer to 750-1,000 pages. Evans is a terrible, verbose writer. I read Domain Driven Design, but I can't recommend it. Surely there's a shorter version someone could recommend? There's only a handful of good ideas in the book which I'm sure could be easily distilled. Domain Driven Design is also a dangerous paradigm to apply everywhere. In fact I suspect that the majority of the time it's a mistake. Specifically the act of hard coding business concepts (products and processes) as first class citizens (classes, services) into your software. This makes your business inflexible and requires engineering effort to iterate on your business processes. It's a poison, and the deeper you build it into your architecture, the deeper the poison seeps, locking you into stale business concepts. Domain Driven Design should be analyzed much more critically than it is, especially given how much time engineers waste slogging through the ramblings of Evan's clouded mind. I highly recommend https://dev.to/cheetah100/domain-driven-disaster-147i https://dev.to/cheetah100/domain-driven-disaster-147i for further reading.

kumarvvr 4y ago
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?
- stevebmark 4y ago
  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).
  - pragmatic 4y ago
    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.
  - rvdginste 4y ago
    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.
Mandatum 4y ago
What’s the copyright law on taking ideas and principals from a book like that, and rewriting it?
- westoncb 4y ago
  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.
  - elyseum 4y ago
    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 https://en.m.wikipedia.org/wiki/Copyright
thinkmassive 4y ago
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.
- abledon 4y ago
  > 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.
dragonwriter 4y ago
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.
- stevebmark 4y ago
  Configuration
  - dragonwriter 4y ago
    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.)
abledon 4y ago
I think its required reading for inheriting large legacy codebases from the early 2000s written in Java; all the insanity suddenly makes sense
elyseum 4y ago
I always found it ironic that a book that advocates concise documentation and diagrams over text looses itself in way too much narrative.

kumarvvr 4y ago

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?

stevebmark 4y ago
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).
- pragmatic 4y ago
  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.
- rvdginste 4y ago
  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.

Mandatum 4y ago

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

westoncb 4y ago
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.
- elyseum 4y ago
  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 https://en.m.wikipedia.org/wiki/Copyright

thinkmassive 4y ago

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.

abledon 4y ago
> 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.

dragonwriter 4y ago

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.

stevebmark 4y ago
Configuration
- dragonwriter 4y ago
  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.)

abledon 4y ago

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

elyseum 4y ago

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