...

Here's a start at listing the proposed modules and their dependencies. This is not the current state of these modules because currently there are several cyclical dependencies (eg Persistence dependencies on Regions, regions depend on persistence). Part of the effort here will be to break these cyclic dependencies by replacing hardcoded references to other modules with plugins and callbacks that are part of the well defined API for each module.

@startuml

@startuml
title Geode Package Dependency Graph
hide members
hide circle
class WAN
WAN --> CacheServer
WAN --> Client
WAN --> Regions
Regions --> CacheServer
Regions --> Client
Regions-->Persistence
Regions-->Statistics
Advisors-->Messaging
Regions-->Advisors
Querying-->Regions
Regions-->Messaging
FunctionService --> Regions
FunctionService --> Messaging
Messaging --> Serialization
PDX --> Serialization
PDX --> Messaging
Regions--> Serialization
Querying--> Serialization
WAN --> Serialization
WAN --> Messaging
Querying -> Messaging
FunctionService --> Serialization
PDX --> Regions
Regions-->OffHeap
Persistence-->Serialization
Advisors-->Serialization
@enduml

...

Package: internal.cache.region

API interfaces/classes: Cache, Region, InternalCache,   InternalRegionService, InternalRegion,

Required Changes:

InternalRegion is new interface for LocalRegion. GemfireCacheImpl, RegionService is a new interface that has the functionality from GemfireCacheImpl to manage regions. LocalRegion, etc. should not be used outside this package.

Direct references to other modules, for example LocalRegion.notifyGatewaySender, should be turned into callbacks that other modules plug into the Region interface. Those callbacks should be tested within the region module.

WAN

Package: internal.cache.wan

...

Required Changes: Operations (The client side code for client-> server messages) for other modules should be moved to their respective packages.

Questions/Issues

What to do with GemfireCacheImpl,Cache?

The Cache interface currently has dependencies on almost all of the modules of geode because it has methods like getQueryService, getGatewaySenders (WAN). Unfortunately, Cache, InternalCache, or GemfireCacheImpl is used as a context object that also passed to almost all modules of Geode.

We need to rework how we inject dependencies into all of these modules. If we want a context object, it should be something that is generic that does not pull in dependencies on all other services, something likes spring's BeanFactory.  But it might be better if the specific dependencies for each module were passed into that module.

Modularity in the public API

We've already started creating a few separate modules at the external level - for example the lucene integration or the auto rebalancer. We need to nail down how these extensions are accessed by the user. One option might be to add a method to Cache like Cache.getService(Class<T> serviceInterface). Maybe we should remove methods like Cache.getQueryService, Cache.getGatewaySenders, etc. in favor of not hardcoding all of the services on Cache?