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.
To address Kasey and Craig's points. I am not claiming that we can create a single solution to meet all needs, rather that software should be designed around function rather than domain. Therefore video editor software cannot be created from a forms and data type application because it is dealing with video functionally. However, many software projects begin with requirements tightly coupled with the domain. Often this leads to software unnecessarily coupled to the domain, and thus limits itself. Imagine the designer of Word getting requirements to write a specific style of letter and writing a word processor around that specific style of letter for a particular industry.
The critique that pushing the domain into configuration leads to complexity in the configuration is valid. In fact the configuration becomes the place you define the domain rules. Just like you can write scripts inside Excel the systems I'm writing allow embedded Javascript which runs server side, and can be replaced with a REST call, by the right administrator of course. Where once there were developers and users we now have a more diverse environment where developers deliver core functionality and business analysts can construct new systems using these tools.
This article was primarily addressing the practice of using the domain as the foundation of the system. In the past this was necessary because of the way databases were static. Adding complex structures at runtime was not possible. Now it is possible, and with this possibility goes new opportunities to dramatically improve development efficiency.
This is not just a supposition. I'm now running the second project using the same software, despite the domains being totally different. We are now looking to develop it into a generally available tool for the entire organization.
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.
To address Kasey and Craig's points. I am not claiming that we can create a single solution to meet all needs, rather that software should be designed around function rather than domain. Therefore video editor software cannot be created from a forms and data type application because it is dealing with video functionally. However, many software projects begin with requirements tightly coupled with the domain. Often this leads to software unnecessarily coupled to the domain, and thus limits itself. Imagine the designer of Word getting requirements to write a specific style of letter and writing a word processor around that specific style of letter for a particular industry.
The critique that pushing the domain into configuration leads to complexity in the configuration is valid. In fact the configuration becomes the place you define the domain rules. Just like you can write scripts inside Excel the systems I'm writing allow embedded Javascript which runs server side, and can be replaced with a REST call, by the right administrator of course. Where once there were developers and users we now have a more diverse environment where developers deliver core functionality and business analysts can construct new systems using these tools.
This article was primarily addressing the practice of using the domain as the foundation of the system. In the past this was necessary because of the way databases were static. Adding complex structures at runtime was not possible. Now it is possible, and with this possibility goes new opportunities to dramatically improve development efficiency.
This is not just a supposition. I'm now running the second project using the same software, despite the domains being totally different. We are now looking to develop it into a generally available tool for the entire organization.