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