Statement driven development

Today most methodologies used model oriented approach.
It can be domain-driven or reverse-engineering, one common point is that they start from a static definition of a model. For domain-driven, it is the domain issued by the development language itself. For the reverse-engineering it starts from a static model structure definition ex: a xsd, wsdl, database schema.
Statement driven development focuses on the actions the developer can run on some models and not the models themselves.
Example: a select statement fetching all the group members a user with group-administrator-role can manage.
Here the statement can be materialized into a search query with sql as implementation.
The important thing for the developer is the query and its I/O not really the underneath model and ... not the decorative technology.

Why Statement-Driven-Development

Couple of articles and limitations make me think that statement driven approach can be a flexible and fast alternative for developpers.
Usually after defining an abstract model such as ORM, the user have to write his UC statements. This means that there is still this second step to perform.


The model is sometimes/often overkill. As a developer, you do not have to apprehend the entire model complexity before yielding productivity.

Limitation on standard

Like in the JOOQ article about function and stored procedure extracting the meta-information can reach some limits when entering in vendor specific particularities.

Native DSL

There is a trend that states that SQL is the only DSL you need.
Why should you wrap it with other technology abstraction that limit its power?

Bye-Bye Domain Objects

...Welcome DTO.

I/O are by essence DTO (why should they be the exact reflection of a persistence layer?). This situation is just a specific exception.

This exception is widely used by multiple apps/framework (strong resuability but limitations).

Remark:

This article is not there to cover the 'everlasting-debate' DO vs. DTO.

SDD just brings a new approach that do not exclude but complement the DDD/Rev-Eng one.

Concretely

MinuteProject for release 0.8.1+ (mid-may-2012) will offer Statement-Driven-Development facilities.

• The user will focus one SQL statement.
• The output will be deduce by the execution of it.
• The input will be easily configurable.

Example

Here is a simple configuration. Statement-model is the new node.

  <model>
    ...
      <statement-model>
           <queries>
               <query name="get address street">
                  <query-body><value><![CDATA[select * from address where addressid > ?]]></value></query-body>
                  <query-params>
                      <query-param name="identifier_Address" is-mandatory="false" type="INT" sample="1"></query-param>
                  </query-params>
               </query>
           </queries>
      </statement-model>
  </model>

This configuration should be enough to get:

• Input bean
• Output bean
• Output list bean
•  All the technology decoration ex for 
• REST CXF: 
• Resource bean with REST path
• spring config
• Native DAO
•  Primefaces SDD

Demonstration will be shipped in Minuteproject next release (0.8.1).

Integrating with REST is pretty much statement-driven: basically you just need to know the URL + its I/O.

Conclusion

• With SDD you focus on the statement and the I/O.
• Minuteproject simplifies the rest (technology wrapper).