One of the recurring patterns I find myself doing that successfully help in creating flexible component based application, is using technology as a driver for my component subdivisions. I usually try to create a domain model component that is completely technology agnostic. By technology agnostic I mean that my domain model should not know anything about HTTP, Web Services, LDAP, Databases, HTML, etc. It should be just an implementation of the business domain (only POJO’s or POCO’s). And usually I end up with a lot of interfaces and abstract classes in my domain model, so that components that are technology-aware are able to implement these interfaces. The important thing here is that the domain component is unaware of any technology or any of its implementors.
Then I have some technology aware components that implement the interfaces of my domain model. So for instance, I have an LDAP component that implements some interface of my domain model, using LDAP technology to fulfill it’s goals. This way the implementation of my domain becomes swappable, so that I am free to replace this component with another implementation, for instance with a SQL implementation. The power of this approach is that my domain model contains the business logic of my application, and requires some information or processing from it’s implementors, but it is unaware ‘how’ this is done. This will give you enormous freedom and flexibility.
Then usually I need final component that wires up everything together. This final component is aware of both the domain model and its implementors. This final component is responsible for wiring up the domain model with the correct implementations. A dependency injection framework could be used for this, or just hard-coding the wiring my also be an option (compile-time validation of your configuration may be a benefit here).
Another benefit of this approach is that you are creating a durable application. I have seen numerous situations where software applications are rebuilt from scratch because the legacy application is to complex to modify, extend or improve. So quite often the decision is made that it is cheaper to rebuild it than continuing working on the current application.
By creating the right dependencies, the right modules or components, you create durable software. Although the there will probably be changes in the business domain through time, in general you business domain can now outlive the implementations it uses. Upgrading to a new technology that is incompatible with the current technology you’re using for a certain implementation now only means creating a new implementation component, re-wiring the application with the new component, and everything keeps working. No need to trash the entire application.
The important principles to keep in mind:
- create technology agnostig domain model components
- create technology aware components that implement implement the domain
- use a single component that wires up your entire application
- think of composing your application from small components instead of one big moloch that does it all, so: composition
