What is it and Why....

Geode in its current form is the ultimate Monolith. Littered with God objects and tight coupling. This makes maintaining and extending the current Geode system really hard, as changing functionality in ObjectA would most inevitably cause a change in ObjectB, which then cause ObjectC having to change, etc...

The current tight coupling of code makes it harder to reason about the expected behavior of the system, as code is layered on top of more code, each layer potentially influencing behavior that is unpredictable.

In order to clean up this  ball of mud we need to refer back to some Good Design Strategies:

1. Separation of Concerns

2. Modularity

3. Abstraction

4. Anticipation of Change

5. Incremental Development

These strategies are best described in the following links:

• Seven Good Design Strategies Part1
• Seven Good Design Strategies Part2
• Seven Good Design Strategies Part3

In additional to the tangible benefits that a modularized system would provide, the extensibility of Geode to allow added functionality like Geode-Lucene support and Geode-Redis Adapter.

Proposal

The proposed architecture is based on trying to meet the following Proposal Goals. The main goals are Separation of Concerns, Modularity, and Abstraction.

This proposal will also cover:

• The definition of a module
• Dependency management of modules
• Library dependencies of a module
• Bootstrapping of a modularized Geode
  • Bootstrapping of individual modules with its dependants

Before there is too much detail one shall paint the picture of Utopia. Picture a world where

Bootstrapping Lifecycle

Upon startup, each module/component will follow the following bootstrapping lifecycle.