ES Java Modules
This document outlines a proposed scheme for organizing and managing the various Java modules (i.e. jar files) that we are beginning to create. The goal is to have a clearly understood hierarchy for these modules and to set out simple rules and guidelines for the creation and the usage of these modules.
Levels
- We are proposing a layered architecture, with layers referred to as levels. Each level will be assigned a number. We expect all developers, particularly technical leads, to become conversant with the level numbers and their meaning.
Here is a prototype level diagram, illustrating our proposed approach:

Working from the bottom up:
Level 4 is the "core" CSF. This is itself a set of modules with its own internal module hierarchy, but as far as applications are concerned, it is one entity "csf". It is intended to house functionality that:
- changes very infrequently.
- is used by all, or the vast majority, of apps.
Level 3 holds services related to what might be called "reference data". This data is generally fairly stable - it changes slowly over time - and examples are Subjects, Departments, Terms etc. This functionality:
- changes infrequently.
- is used by many, but not necessarily all, apps.
Level 2 contains services related to business logic, and data that does change frequently. The modules are intended to be scoped around single business processes (e.g. registration, grading, student accounts). This functionality:
- changes more frequently.
- is used by apps needing the business