"The first reason domain driven development is a bad idea is that it encourages you to build business logic into the application."
Literally, what? --- maybe you should acknowledge some scope here because this is literally what many of us are paid to do. This would be a terrible idea if you were building software for people outside of your company (e.g. generic solutions like database software, or products that meant to be pulled off the shelf), but for many of us if not most of us, we build software to run the companies we work for. In that case, the statement that building business logic into the software is a bad thing is patently absurd. That doesn't make DDD bad, that makes using DDD in a non-domain context bad. Like trying to tighten a lug nut with a banana.
Peter is the former President of the New Zealand Open Source Society. He is currently working on Business Workflow Automation, and is the core maintainer for Gravity Workflow a GPL workflow engine.
"for many of us if not most of us we build software to run the comanies we work for." Yes yes, so do I, but by using a platform which is not strongly tied to any domain you can deliver systems which are configured at runtime that are easily adaptable and flexible. No development life cycle. This is what agile means. You can make modifications in runtime systems. The more you hard code the business rules the less flexible the software. Configure business rules instead. Configure data structures. Configure integrations, queries, visualizations and so on. In a way this is still 'development', only it hands power back to users.
The more business logic you add on your application, the easiest it is to test them. If the stakeholders wanted something to configure, that should have clearly stated so. Giving them something "not strongly tied" it's basically giving them something anemic (considered an anti - pattern for the sole reason of a system being able to be used by oranges and apples at the same time, and quite very always having weird behaviour for both at the same time)
The less flexible software, the easier it is to change. The fastest you're pipelines and safer you'll feel -on teh development cycle - where solving something could literally 5 minutes.
Flexibility can be very quickly substituted by ambiguity.
The only reason you think this way is because you lack knowledge for building clean code. You need to know about clean architecutre/ hexagonal architecture, DDD and CQRS patterns, OO patterns and SOLID.
With those tools, you won't need to argue thater argue to "not have logic tied" to the business.
On the other hand, for "anemic" solution there are aplenty, they are called wordpress, drupal, CMS, etc. Then is the job of the "site builder" using the given tools to create a solution. What happens with this? Very rapidly you reach a non scalable point, specific use cases are very hard because there's always something very specific domain thing that will need custom development, and that is the source of all frustration of all the developers that don't know better.
I am sorry but this article is dangerous, in encourages bad practices in the industry, it will lead to greats amount of frustration, of developers being caught in a Sisyphus kind of development where firefighting is the normal, and where the code is completely so non understandable since it's used as "generic" as possible.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
"The first reason domain driven development is a bad idea is that it encourages you to build business logic into the application."
Literally, what? --- maybe you should acknowledge some scope here because this is literally what many of us are paid to do. This would be a terrible idea if you were building software for people outside of your company (e.g. generic solutions like database software, or products that meant to be pulled off the shelf), but for many of us if not most of us, we build software to run the companies we work for. In that case, the statement that building business logic into the software is a bad thing is patently absurd. That doesn't make DDD bad, that makes using DDD in a non-domain context bad. Like trying to tighten a lug nut with a banana.
" ... software to run the companies we work for..." , well that seems to be more often than not: Excell.
"for many of us if not most of us we build software to run the comanies we work for." Yes yes, so do I, but by using a platform which is not strongly tied to any domain you can deliver systems which are configured at runtime that are easily adaptable and flexible. No development life cycle. This is what agile means. You can make modifications in runtime systems. The more you hard code the business rules the less flexible the software. Configure business rules instead. Configure data structures. Configure integrations, queries, visualizations and so on. In a way this is still 'development', only it hands power back to users.
The more business logic you add on your application, the easiest it is to test them. If the stakeholders wanted something to configure, that should have clearly stated so. Giving them something "not strongly tied" it's basically giving them something anemic (considered an anti - pattern for the sole reason of a system being able to be used by oranges and apples at the same time, and quite very always having weird behaviour for both at the same time)
The less flexible software, the easier it is to change. The fastest you're pipelines and safer you'll feel -on teh development cycle - where solving something could literally 5 minutes.
Flexibility can be very quickly substituted by ambiguity.
The only reason you think this way is because you lack knowledge for building clean code. You need to know about clean architecutre/ hexagonal architecture, DDD and CQRS patterns, OO patterns and SOLID.
With those tools, you won't need to argue thater argue to "not have logic tied" to the business.
On the other hand, for "anemic" solution there are aplenty, they are called wordpress, drupal, CMS, etc. Then is the job of the "site builder" using the given tools to create a solution. What happens with this? Very rapidly you reach a non scalable point, specific use cases are very hard because there's always something very specific domain thing that will need custom development, and that is the source of all frustration of all the developers that don't know better.
I am sorry but this article is dangerous, in encourages bad practices in the industry, it will lead to greats amount of frustration, of developers being caught in a Sisyphus kind of development where firefighting is the normal, and where the code is completely so non understandable since it's used as "generic" as possible.