Spike - Decouple Application Module

Introduction

The purpose of the spike was to see if it was possible to create another module and pull out code from the monolithic application module into another module. (now called appdomain)

Why?

At present we are creating service facades (application services) which at present are used by the presentation layer but which we also want to expose these for use by tests and in future for data migration use. At present this is not possible becuase code from application is released as class files within a WAR archive. We would like the services to be exposed within a JAR so people could use its dependency and launch an application context with platform services running.

Findings:

The top down approach (extracting service facades) is ongoing but just doing service facades will mean they are still not reuseable.

1) Tried bottom up approach extracting out base classes and refactoring where possible to decouple for other dependencies in an attempt to bring in 'savings' related classes and dependencies. The level of coupling was too much so no surprise there.

2) Spent a bit of time concentrating on removing 'persistence' dependencies from core domain classes like 'AccountBO'. Taking this middle-up approach was successful enough but the level of refactoring required is just too much.

Conclusion

The only feasible way at present to make services releasable/reuseable from a JAR file is to pull out all non ui/mvc related code from application and put into another module that produces a JAR that application will depend on.

This will allow use to use services as we implement them and we can focus on untangling the 'tight coupling' in a top down incremental manner.