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.
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.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.