Hi,
As part of my investigation for DERBY-3351 I am looking at the ways
in which modules interact with each other.
From an overall layered architecture viewpoint, I feel that the
rules should be that:
Services layer should not have a dependency on or knowledge of any of
the higher layers.
The Store layer will depend upon the Services layer, but may not
depend on or have knowledge of any of the higher layers.
The Language layer (compilation and execution) can depend upon
components in Store or Services layer, but must not depend on or have
knowledge of components in the JDBC layer.
The JDBC layer can depend upon components in any of the layers.
It seems that this was the original design anyway, although the rules
for interaction may not have been stated explicitly.
In each layer, Derby has well-defined modules or components, with
defined responsibilities. Roughly speaking, a module has an API, and
an implementation.
At the module level, the rule should be that modules may interact
with other modules only through the API, and not through any
implementation details.
And of course, it is better that the API should be made up of
interfaces, rather than classes.
Again, it seems to me that this is generally true in Derby, and is
consistent with the original design.
While most of the Derby code is well-behaved with respect to the
rules above, there are occasions when the inter-module dependencies
appear unsatisfactory. Here is a sample:
1) The org.apache.derby.iapi.reference package contains constants
that go across the boundaries of the layers. I can see the rationale
behind having a central location for reference data, but would it be
better from a modularity perspective, for each of the layers to have
its own reference data?
2) A somewhat similar but different issue is that all the Stored
Format Ids of all objects, regardless of layer, module, etc., is
stored in org.apache.derby.iapi.services.io.StoredFormatIds. In this
case, it is probably better to externalize this information and load
it at system startup.
3) org.apache.derby.iapi.error.StandardException contains references
to org.apache.derby.impl.jdbc.EmbedSQLException,
org.apache.derby.impl.jdbc.Util.
StandardException also has knowledge about EmbedSQLException.
4) ShutdownException and ErrorStringBuilder are probably better
placed in org.apache.derby.iapi.error, than in their present location
org.apache.derby.iapi.services.context.
I would like to submit patches to fix some of these and similar
issues, but before doing so, would like to know if there are any
violent objections to the general module interaction principles
stated above.
Regards
Dibyendu
