ERP Modules with GWT and Domain Driven Architecture

If you've had a chance to explore the technical framework of opentaps Open Source ERP + CRM, or indeed any modern ERP system, you would find it probably look something like this:

There is a data model, or entities, which is connected to a relational database. Above that there is a tier of business logic, or services. The combination of entities and services is what is usually called "model" of the model-view-controller architecture. Finally, there is a view layer which creates the screens that the users see, and the view layer interacts with the services through a controller.

When you need to add something to your ERP system, you would need to create new entities, new services, new entries in your controller, and new screens in your view layer:

This, in turn, also means learning the technical framework of the particular ERP system. If later you wanted to add the same features to another ERP system, it would mean learning a different technical framework, then creating adding to its entities, services, and view layer.

Now let's consider this approach, which leverages the Google Web Toolkit (GWT) and the Domain Driven Architecture:

Instead of becoming a part of the ERP system, the new feature sits as its own module. It has its own self-contained "model" tier, including the entities and services that it needs. There is a repository interface which defines the actual database interactions that this module would need, such as what kind of data it would need to retrieve and persistent. Its view layer is written with the Google Web Toolkit, and it plugs into the rest of the ERP system. It takes its parameters from HTML embedded in the ERP system's screens and returns its output as a widget.

Finally, to interact with the ERP system, an implementation of the module's repository interface is written for this particular ERP system. This implementation could use either Web services to connect to the business logic or services tier of the ERP system, connect more directly to the entities or persistence layer of the ERP system, or bypass both and simply obtain a JDBC connection from the ERP system and interact with its database directly.

The advantage of this alternative approach is that the module could in turn be adapted to other ERP systems simply by changing the implementation of the repository interface:

For all three ERP systems, the user interface of the module can be integrated into existing screens as widgets. The same module could be adapted to ERP-A and ERP-C in the diagram by implementing different repositories for those two ERP systems. The example for ERP-B shows another configuration: only the user interface is integrated into the ERP system's screens. The module supplies its own persistence, by implementing a repository which talks to an independent database. This approach could be helpful if the module's features do not overlap with the core ERP system, or if interacting with the core ERP system is too difficult.