I've been thinking about a project scaffolding tool for Java for a long time now. Many modern technologies now come with CLIs that can lay down project skeletons and add conventional concerns by simply executing command line actions. This scaffolding, as it has come to be known, jump-starts project work significantly by laying down the typical boilerplate and, in many cases, simplifies the wiring of ancillary technologies.
As a top-tier technology, Java has benefited from the many available IDEs that also provide scaffolding-like functionality. These IDEs, and even Maven archetypes to some extent, provide very powerful tools for project foundations and instrumentation of specialized components. You are even able to produce your own extension, provided you're willing to figure out some of the rather obscure mechanisms to do so.
However, architectural patterns change very rapidly and IDEs fail to keep pace. Plus, the IDE capabilities are usually driven through user interface interaction, so there's no repeat-ability or auditing of the process involved with scaffolding an application. Additionally, any scaffolding system currently available falls short of delivering a complete application. In my opinion, these shortcomings result in a significantly lost opportunity.
Imagine you can define your application's domain model, behaviors, and workflows independently of technology, architecture, and patterns. Now imagine that you can run that definition through an enhanced scaffolding mechanism (ESM) capable of generating your entire application using any technology, following any architecture, and implementing any set of patterns. That would be miraculous!
I believe that Spring Roo is a technology capable of delivering on that proposition. It has the mechanisms to deliver that promise and it's up to us to unlock the potential of decoupling the application domain from its underlying architecture. This is a very tough problem to solve and many have tried.
To me, the most incredible benefit is a system that is capable of generating the entirety of an application merely from a description. Extending an application is a simple matter of adding or changing the description. Refactoring is a simple matter of updating the generation components and then passing the description through the ESM again. When you want to change the entire architecture of the deployment model, select a different ESM model. The build pipeline could just accept the application description and generate the code during the build process.
I will be conducting a series of experiments with Spring Roo and creating some "add-ons" in order to test these theories and I hope you find them interesting.
As a top-tier technology, Java has benefited from the many available IDEs that also provide scaffolding-like functionality. These IDEs, and even Maven archetypes to some extent, provide very powerful tools for project foundations and instrumentation of specialized components. You are even able to produce your own extension, provided you're willing to figure out some of the rather obscure mechanisms to do so.
However, architectural patterns change very rapidly and IDEs fail to keep pace. Plus, the IDE capabilities are usually driven through user interface interaction, so there's no repeat-ability or auditing of the process involved with scaffolding an application. Additionally, any scaffolding system currently available falls short of delivering a complete application. In my opinion, these shortcomings result in a significantly lost opportunity.
Imagine you can define your application's domain model, behaviors, and workflows independently of technology, architecture, and patterns. Now imagine that you can run that definition through an enhanced scaffolding mechanism (ESM) capable of generating your entire application using any technology, following any architecture, and implementing any set of patterns. That would be miraculous!
I believe that Spring Roo is a technology capable of delivering on that proposition. It has the mechanisms to deliver that promise and it's up to us to unlock the potential of decoupling the application domain from its underlying architecture. This is a very tough problem to solve and many have tried.
To me, the most incredible benefit is a system that is capable of generating the entirety of an application merely from a description. Extending an application is a simple matter of adding or changing the description. Refactoring is a simple matter of updating the generation components and then passing the description through the ESM again. When you want to change the entire architecture of the deployment model, select a different ESM model. The build pipeline could just accept the application description and generate the code during the build process.
I will be conducting a series of experiments with Spring Roo and creating some "add-ons" in order to test these theories and I hope you find them interesting.
Comments
Post a Comment