1. collect clients’ or personal needs
2. design the relational model (database design)
3. scaffold the extension using the kickstarter
4. add a lot of database queries template handling to the file _pi1, _pi2, _pi3 etc.
5. design the templates

This ends up in an extension design which is hard to maintain – especially for larger projects. A more modern approach uses the Model View Controller Pattern. One of the advantages of this pattern is to enable the developer to focus on the domain of the client (and thus the domain model of the extension). So, the MVC pattern is a prerequisite for Domain Driven Design. This leads to a slightly different development process:

1. collect clients or personal needs
2. design the domain model (classes) translating the domain knowledge of the client into UML
3. scaffolding the extension using a kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The domain model is more decoupled from the implementation architecture.
• It’s clearly defined where the business logic resides (in the domain model classes).

… and the cons

• It adds complexity to the extension.
• It forces the developer to learn new programing paradigms, which might be difficult to schedule in the daily work.

To be consequent we have to go one step further. The domain knowledge is captured in natural language. But natural language is much more expressive than object oriented software design in UML. As a consequence, there is a mismatch between the domain model expressed by the domain experts (the client) and the object oriented model expressed in UML.

If we want to keep all the information of the domain experts we have to define an ontology. To express the domain knowledge in an ontology, OWL seems to be a good solution to me, as it is a W3C standard and targets web applications. To edit ontologies I played around with Protégé.

In the end, we will have a process which can be named “Ontology Driven Extension Development Process”:

1. collect clients or personal needs
2. design the ontology using the same language as the client does
3. scaffolding the extension using a new ontology driven kickstarter
4. adding the business logic to the domain model classes
5. design the templates

What are the pros of this approach

• The developer and the client use a common language.
• The ontology based domain model is independent from the implementation and can be shared across different extensions with different purposes.

… and the cons

• It adds complexity to the development processes.
• It’s forces the developer to learn completely new paradigms an terms.

I’m looking forward to your comments an appreciate any questions.