You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by ak...@apache.org on 2004/02/04 07:11:20 UTC
svn commit: rev 6474 - in incubator/directory/eve/trunk/eve/xdocs: . backend design frontend
Author: akarasulu
Date: Tue Feb 3 22:11:20 2004
New Revision: 6474
Added:
incubator/directory/eve/trunk/eve/xdocs/building.xml
incubator/directory/eve/trunk/eve/xdocs/components.xml
- copied unchanged from rev 6463, incubator/directory/eve/trunk/eve/xdocs/design/components.xml
incubator/directory/eve/trunk/eve/xdocs/deploying.xml
incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml
Removed:
incubator/directory/eve/trunk/eve/xdocs/design/components.xml
Modified:
incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml
incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml
incubator/directory/eve/trunk/eve/xdocs/design/scm.xml
incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml
incubator/directory/eve/trunk/eve/xdocs/navigation.xml
Log:
moving things around a little
Modified: incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml (original)
+++ incubator/directory/eve/trunk/eve/xdocs/backend/navigation.xml Tue Feb 3 22:11:20 2004
@@ -21,7 +21,7 @@
<item name="Overview" href="../../index.html"/>
<item name="Community" href="../../community/index.html"/>
<item name="Latest News" href="../../news.html"/>
- <item name="Sub-Projects" href="../../subprojects/index.html">
+ <item name="Subprojects" href="../../subprojects/index.html">
<item name="Eve" href="/index.html">
<item name="Design" href="/design/index.html"/>
<item name="Features" href="/features.html"/>
@@ -38,6 +38,7 @@
</menu>
<menu name="Resources">
+ <item name="IRC" href="../../irc.html"/>
<item name="Jira" href=
"http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
Added: incubator/directory/eve/trunk/eve/xdocs/building.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/building.xml Tue Feb 3 22:11:20 2004
@@ -0,0 +1,42 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Apache Directory Project: Building Eve</title>
+ </properties>
+
+ <body>
+ <section name="TODO">
+ <ul>
+ <li>
+ Describe Maven based build and use of POM extension with reactor.
+ </li>
+
+ <li>
+ Describe the organization of projects from the POV of the POM.
+ </li>
+
+ <li>
+ Discuss use of a component documentation plugin that uses our
+ layout and some container information to automatically generate
+ component documentation.
+ </li>
+
+ <li>
+ Document goals in maven.xml and what they do.
+ </li>
+
+ <li>
+ Discuss per project document generation and how that integrates with
+ subproject documents.
+ </li>
+ </ul>
+ </section>
+
+ <section name="Building Eve">
+ <p>
+ Coming soon ...
+ </p>
+ </section>
+ </body>
+</document>
\ No newline at end of file
Added: incubator/directory/eve/trunk/eve/xdocs/deploying.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/deploying.xml Tue Feb 3 22:11:20 2004
@@ -0,0 +1,30 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Apache Directory Project: Building Eve</title>
+ </properties>
+
+ <body>
+ <section name="TODO">
+ <ul>
+ <li>
+ Figure out what deployment will take but this is way out there.
+ </li>
+
+ <li>
+ Perhaps there will be some deployment tools we can build to help
+ configure server components as the server is deployed along with
+ an installer.
+ </li>
+ </ul>
+ </section>
+
+ <section name="Deploying Eve">
+ <p>
+ Coming later ...
+ </p>
+ </section>
+
+ </body>
+</document>
Modified: incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml (original)
+++ incubator/directory/eve/trunk/eve/xdocs/design/navigation.xml Tue Feb 3 22:11:20 2004
@@ -21,11 +21,13 @@
<item name="Overview" href="../../index.html"/>
<item name="Community" href="../../community/index.html"/>
<item name="Latest News" href="../../news.html"/>
- <item name="Sub-Projects" href="../../subprojects/index.html">
+ <item name="Subprojects" href="../../subprojects/index.html">
<item name="Eve" href="/index.html">
<item name="Design" href="/design/index.html">
- <item name="SCM" href="/design/scm.html"/>
+ <item name="Repository Layout" href="/design/repo-layout.html"/>
<item name="Components" href="/design/components.html"/>
+ <item name="Building" href="/design/building.html"/>
+ <item name="Deploying" href="/design/deploying.html"/>
</item>
<item name="Features" href="/features.html"/>
<item name="Backend" href="/backend/index.html"/>
@@ -41,6 +43,7 @@
</menu>
<menu name="Resources">
+ <item name="IRC" href="../../irc.html"/>
<item name="Jira" href=
"http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
Modified: incubator/directory/eve/trunk/eve/xdocs/design/scm.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/design/scm.xml (original)
+++ incubator/directory/eve/trunk/eve/xdocs/design/scm.xml Tue Feb 3 22:11:20 2004
@@ -6,287 +6,5 @@
</properties>
<body>
- <section name="Overview">
- <p>
- The design for a project has as much to do with how the source code is
- organized as it does the structure of the program. This section
- discusses the software configuration management principals used to
- organize, maintain and build Eve's code base.
- </p>
- <p>
- After reading this section you should have gained the following:
- </p>
-
- <ul>
- <li>
- Know how the repo is organized and why
- </li>
-
- <li>
- Ability to navigate source and add to it
- </li>
-
- <li>
- Know how to build and deploy Eve
- </li>
- </ul>
- </section>
-
- <section name="Resources">
- <p>
- While reading the next section you might want to use the following
- resources:
- </p>
-
- <table>
- <tr><th>Resource</th></tr>
- <tr>
- <td><a href="http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve?root=Apache-SVN">
- Eve's Subversion Repository</a></td>
- </tr>
-
- <tr><td>
- <a href="../../../svn.html">
- Subversion Documentation</a></td>
- </tr>
- </table>
- </section>
-
- <section name="Organization">
- <subsection name="Repository Layout">
- <p>
- Within the Subversion repository Eve contains several small Maven
- projects that are consolidated into groups based on subsystem. Each
- component within Eve has at least two separate Maven
- projects. The layout of component and API projects are based on
- Eve's structure.
- </p>
-
- <p>
- A logical distinction is made between various subsystems whose
- components are separated out in a heirarchy based on function within
- the source code repository. The aspects of each subsystem shall be
- discussed in detail within the documentation set for that subsystem.
- Developers looking at Eve's source should know that the Subversion
- repository is structured to mimic this component containment
- heirarchy. Here's a brief listing of the directory structure we're
- referring to:
- </p>
-
- <source>
-./eve -- top component projects and subsystems
- ./frontend -- contains frontend subsystem APIs and service projects
- ./common -- contains shared code common to frontend subsystem
- ./api -- API common to all projects in frontend
- ./buffer -- frontend buffer service projects
- ./spi -- frontend buffer service provider interface project
- ./pojo-impl -- frontend buffer component POJO implementation project
- ./merlin-impl -- frontend buffer component Merlin implementation project
- ./event -- frontend SEDA event dispatcher service projects
- ./spi -- frontend event dispatcher SPI project
- ./pojo-impl -- frontend event dispatcher POJO implementation project
- ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
- ...
- ./backend
- ...
- </source>
-
- <p>
- The structure above my nest deeper for other subsystems. For example
- the backend subsystem has within it other sub subsystems. Each nested
- subsystem adds an extra level of directory depth. In turn this
- subsystem may have other subsystems and/or component directories that
- have an SPI and an implementation project.
- </p>
- </subsection>
-
- <subsection name="Subsystem Directories and Common APIs">
- <p>
- Eve is composed of components and these components are logically
- grouped into subsystems. For more on Eve's component oriented design
- aspects take a look <a href="./components.html">here</a>.
- </p>
-
- <p>
- Subsystems may contain a common directory used to centralize some
- classes shared by the subsystem as a common subsystem API of sorts.
- Centralization of common code helps localize domain specific classes
- and interfaces for a subsystem assigned to a specific function. Take
- for example the minor schema subsystem which resides under the
- backend subsystem. The schema subsystem contains a common API for
- the various interfaces and classes representing schema objects found
- within LDAP and X.500.
- </p>
-
- <p>
- The most benefit we gain from these subsystem common APIs is in the
- area of project dependency management. Natural class dependencies
- will exist within a subsystem. When dependent classes are distributed
- across several Maven projects within the subsystem interproject
- dependencies are introduced. By design dependencies between projects
- will exist to lightly couple the subsystem. However these class
- dependencies should not drive the project dependencies between
- services and components. If class dependencies are allowed to drive
- project dependencies, you quickly find a web of cyclic project
- dependencies creating build problems.
- </p>
- </subsection>
-
- <subsection name="Service/Component Directories">
- <p>
- The COP based approach as we said is discussed in more detail
- within the component design documentation. However we discuss the
- effects this has on the layout of the subsystem services and the
- components that implement them within the software repository.
- </p>
-
- <p>
- Components have a service interface and one or more implementations.
- For reasons described within component documentation we separate out
- the service interface into its own jar along with other helper classes
- and interfaces. Each implementation is also packaged into its own
- jar. Each jar is essentially built by a separate Maven project. For
- each service within a subsystem, a top level directory is named after
- the service like the <em>eve/frontend/buffer</em> directory for the
- buffer service within the frontend subsystem. The buffer service
- creates and pools expensive direct memory buffers for the frontend.
- The service interface is kept within an <em>'spi'</em> project
- directory and an implementation is defined within a <em>'pojo-impl'
- </em> directory. Other implementations of the service may also get
- their own directory. For example the Merlin specific wrappers may be
- packaged under another implementation directory like <em>'merlin-impl'
- </em>.
- </p>
-
- <p>
- The service directory layout pattern is simple and outlined below:
- </p>
-
- <table>
- <tr><th>Directory</th><th>Purpose</th><th>Number</th></tr>
-
- <tr>
- <td>
- *spi
- </td>
- <td>
- contains the SPI jar project
- </td>
- <td>
- In the immortal words of the highlander, "there can only be one!"
- </td>
- </tr>
-
- <tr>
- <td>
- *pojo-impl
- </td>
- <td>
- contains projects for components that implement the service and
- are plain old java objects: they depend on the SPI project
- </td>
- <td>
- one or more: some services have bootstrap and solidstate versions
- and may have more than one implementation
- </td>
- </tr>
-
- <tr>
- <td>
- [container]-*-impl
- </td>
- <td>
- contains projects for components that implement the service and
- are wrappers around the plain old java objects for specific
- containers: they depend on the SPI project and the POJO
- implementations. Examples are merlin-impl, loom-impl ...
- </td>
- <td>
- one or more: when we start amassing wrappers for various IoC
- containers we'll add them here.
- </td>
- </tr>
-
- </table>
- </subsection>
-
- <subsection name="Why go to such lengths?">
- <p>
- One might ask why we have gone to such lengths to separate out our
- code in this fashion with projects for each service SPI and projects
- for each implementation.
- </p>
-
- <ul>
- <li>
- Source code configuration is just as important as the code,
- sometimes more so - going the distance is worth it.
- </li>
-
- <li>
- Clean and clear management of project dependencies.
- </li>
-
- <li>
- Project directory names clearly imply the purpose. SPI is for
- service interfaces. And the implementations can be differentiated
- with respect to their design (POJO) or the container they're
- destined to run in.
- </li>
-
- <li>
- Conformance to this pattern down the road will make configuration
- and deployment to various containers easier to maintain and
- fuctionality to perform these tasks may be shared.
- </li>
-
- <li>
- Container Classloader heirachies can hang multiple implementations
- under an SPI Classloader if the SPI and implementations are kept
- separate.
- </li>
-
- <li>
- A separation of concerns: those interested in a specific container
- don't care about the wrapper implementation, setup and configuration
- of the wrapper implementations for other containers.
- </li>
-
- <li>
- One pleseant side-effect is that it makes people stop and think
- about what they are doing in terms of service interfaces and
- component implementations.
- </li>
-
- <li>
- It makes sense to keep a subsystem's nested subsystems and its
- services together under one directory. This way the directory
- heirarchy models the project and service dependencies within the
- system.
- </li>
-
- <li>
- It makes sense to keep the implementations of a service interface
- together under on umbrella directory for the service.
- </li>
- </ul>
- </subsection>
- </section>
-
- <section name="Building Eve">
- <p>
- Put something here about how we use maven and talk about reactor and
- the organization of projects. Talk about documentation and site
- content generation. Talk about the use of a component documentation
- plugin.
- </p>
- </section>
-
- <section name="Deploying Eve">
- <p>
- Talk about deployment tools and issues pertaining to the container.
- </p>
- </section>
-
</body>
</document>
Modified: incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml (original)
+++ incubator/directory/eve/trunk/eve/xdocs/frontend/navigation.xml Tue Feb 3 22:11:20 2004
@@ -21,7 +21,7 @@
<item name="Overview" href="../../index.html"/>
<item name="Community" href="../../community/index.html"/>
<item name="Latest News" href="../../news.html"/>
- <item name="Sub-Projects" href="../../subprojects/index.html">
+ <item name="Subprojects" href="../../subprojects/index.html">
<item name="Eve" href="/index.html">
<item name="Design" href="/design/index.html"/>
<item name="Features" href="/features.html"/>
@@ -38,6 +38,7 @@
</menu>
<menu name="Resources">
+ <item name="IRC" href="../../irc.html"/>
<item name="Jira" href=
"http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
Modified: incubator/directory/eve/trunk/eve/xdocs/navigation.xml
==============================================================================
--- incubator/directory/eve/trunk/eve/xdocs/navigation.xml (original)
+++ incubator/directory/eve/trunk/eve/xdocs/navigation.xml Tue Feb 3 22:11:20 2004
@@ -21,12 +21,15 @@
<item name="Overview" href="../../index.html"/>
<item name="Community" href="../../community/index.html"/>
<item name="Latest News" href="../../news.html"/>
- <item name="Sub-Projects" href="../../subprojects/index.html">
+ <item name="Subprojects" href="../../subprojects/index.html">
<item name="Eve" href="/index.html">
- <item name="Design" href="/design/index.html"/>
<item name="Features" href="/features.html"/>
- <item name="Backend" href="/backend/index.html"/>
- <item name="Frontend" href="/frontend/index.html"/>
+ <item name="Source Layout" href="/source-layout.html"/>
+ <item name="Components" href="/components.html"/>
+ <item name="Building" href="/building.html"/>
+ <item name="Deploying" href="/deploying.html"/>
+ <item name="Backend Subsystem" href="/backend/index.html"/>
+ <item name="Frontend Subsystem" href="/frontend/index.html"/>
</item>
<item name="LDAP" href="../ldap/index.html"/>
<item name="Janus" href="../janus/index.html"/>
@@ -38,6 +41,7 @@
</menu>
<menu name="Resources">
+ <item name="IRC" href="../../irc.html"/>
<item name="Jira" href=
"http://nagoya.apache.org/jira/secure/BrowseProject.jspa?id=10400"/>
<item name="Wiki" href="http://wiki.apache.org/directory"/>
Added: incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml
==============================================================================
--- (empty file)
+++ incubator/directory/eve/trunk/eve/xdocs/repo-layout.xml Tue Feb 3 22:11:20 2004
@@ -0,0 +1,269 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<document>
+ <properties>
+ <author email="akarasulu@apache.org">Alex Karasulu</author>
+ <title>Apache Directory Project: Repository Layout</title>
+ </properties>
+
+ <body>
+ <section name="Overview">
+ <p>
+ The design for a project has as much to do with how the source code is
+ organized as it does the structure of the program. This section
+ discusses the configuration management techniques used to organize
+ Eve's source code.
+ </p>
+ <p>
+ After reading this section you should have gained the following:
+ </p>
+
+ <ul>
+ <li>
+ Know how the repo is organized and why
+ </li>
+
+ <li>
+ Ability to navigate source and add to it
+ </li>
+ </ul>
+
+ <subsection name="Resources">
+ <p>
+ While reading the next section you might want to use the following
+ resources:
+ </p>
+
+ <table>
+ <tr><th>Resource</th></tr>
+ <tr>
+ <td><a href="http://cvs.apache.org/viewcvs.cgi/incubator/directory/eve/trunk/eve?root=Apache-SVN">
+ Eve's Subversion Repository</a></td>
+ </tr>
+
+ <tr><td>
+ <a href="../../../svn.html">
+ Subversion Documentation</a></td>
+ </tr>
+ </table>
+ </subsection>
+ </section>
+
+ <section name="Repository Layout">
+ <p>
+ Within the Subversion repository Eve contains several small Maven
+ projects that are consolidated into groups based on subsystem. Each
+ component within Eve has at least two separate Maven
+ projects. The layout of component and API projects are based on
+ Eve's structure.
+ </p>
+
+ <p>
+ A logical distinction is made between various subsystems whose
+ components are separated out in a heirarchy based on function within
+ the source code repository. The aspects of each subsystem shall be
+ discussed in detail within the documentation set for that subsystem.
+ Developers looking at Eve's source should know that the Subversion
+ repository is structured to mimic this component containment
+ heirarchy. Here's a brief listing of the directory structure we're
+ referring to:
+ </p>
+
+ <source>
+./eve -- top component projects and subsystems
+ ./frontend -- contains frontend subsystem APIs and service projects
+ ./common -- contains shared code common to frontend subsystem
+ ./api -- API common to all projects in frontend
+ ./buffer -- frontend buffer service projects
+ ./spi -- frontend buffer service provider interface project
+ ./pojo-impl -- frontend buffer component POJO implementation project
+ ./merlin-impl -- frontend buffer component Merlin implementation project
+ ./event -- frontend SEDA event dispatcher service projects
+ ./spi -- frontend event dispatcher SPI project
+ ./pojo-impl -- frontend event dispatcher POJO implementation project
+ ./merlin-impl -- frontend event dispatcher Merlin wrapper impl project
+ ...
+ ./backend ...
+ </source>
+
+ <p>
+ The structure above my nest deeper for other subsystems. For example
+ the backend subsystem has within it other sub subsystems. Each nested
+ subsystem adds an extra level of directory depth. In turn this
+ subsystem may have other subsystems and/or component directories that
+ have an SPI and an implementation project.
+ </p>
+ </section>
+
+ <section name="Subsystem Directories and Common APIs">
+ <p>
+ Eve is composed of components and these components are logically
+ grouped into subsystems. For more on Eve's component oriented design
+ aspects take a look <a href="./components.html">here</a>.
+ </p>
+
+ <p>
+ Subsystems may contain a common directory used to centralize some
+ classes shared by the subsystem as a common subsystem API of sorts.
+ Centralization of common code helps localize domain specific classes
+ and interfaces for a subsystem assigned to a specific function. Take
+ for example the minor schema subsystem which resides under the
+ backend subsystem. The schema subsystem contains a common API for
+ the various interfaces and classes representing schema objects found
+ within LDAP and X.500.
+ </p>
+
+ <p>
+ The most benefit we gain from these subsystem common APIs is in the
+ area of project dependency management. Natural class dependencies
+ will exist within a subsystem. When dependent classes are distributed
+ across several Maven projects within the subsystem interproject
+ dependencies are introduced. By design dependencies between projects
+ will exist to lightly couple the subsystem. However these class
+ dependencies should not drive the project dependencies between
+ services and components. If class dependencies are allowed to drive
+ project dependencies, you quickly find a web of cyclic project
+ dependencies creating build problems.
+ </p>
+ </section>
+
+ <section name="Service/Component Directories">
+ <p>
+ The COP based approach as we said is discussed in more detail
+ within the component design documentation. However we discuss the
+ effects this has on the layout of the subsystem services and the
+ components that implement them within the software repository.
+ </p>
+
+ <p>
+ Components have a service interface and one or more implementations.
+ For reasons described within component documentation we separate out
+ the service interface into its own jar along with other helper classes
+ and interfaces. Each implementation is also packaged into its own
+ jar. Each jar is essentially built by a separate Maven project. For
+ each service within a subsystem, a top level directory is named after
+ the service like the <em>eve/frontend/buffer</em> directory for the
+ buffer service within the frontend subsystem. The buffer service
+ creates and pools expensive direct memory buffers for the frontend.
+ The service interface is kept within an <em>'spi'</em> project
+ directory and an implementation is defined within a <em>'pojo-impl'
+ </em> directory. Other implementations of the service may also get
+ their own directory. For example the Merlin specific wrappers may be
+ packaged under another implementation directory like <em>'merlin-impl'
+ </em>.
+ </p>
+
+ <p>
+ The service directory layout pattern is simple and outlined below:
+ </p>
+
+ <table>
+ <tr><th>Directory</th><th>Purpose</th><th>Number</th></tr>
+
+ <tr>
+ <td>
+ *spi
+ </td>
+ <td>
+ contains the SPI jar project
+ </td>
+ <td>
+ In the immortal words of the highlander, "there can only be one!"
+ </td>
+ </tr>
+
+ <tr>
+ <td>
+ *pojo-impl
+ </td>
+ <td>
+ contains projects for components that implement the service and
+ are plain old java objects: they depend on the SPI project
+ </td>
+ <td>
+ one or more: some services have bootstrap and solidstate versions
+ and may have more than one implementation
+ </td>
+ </tr>
+
+ <tr>
+ <td>
+ [container]-*-impl
+ </td>
+ <td>
+ contains projects for components that implement the service and
+ are wrappers around the plain old java objects for specific
+ containers: they depend on the SPI project and the POJO
+ implementations. Examples are merlin-impl, loom-impl ...
+ </td>
+ <td>
+ one or more: when we start amassing wrappers for various IoC
+ containers we'll add them here.
+ </td>
+ </tr>
+
+ </table>
+ </section>
+
+ <section name="Why go to such lengths?">
+ <p>
+ One might ask why we have gone to such lengths to separate out our
+ code in this fashion with projects for each service SPI and projects
+ for each implementation.
+ </p>
+
+ <ul>
+ <li>
+ Source code configuration is just as important as the code,
+ sometimes more so - going the distance is worth it.
+ </li>
+
+ <li>
+ Clean and clear management of project dependencies.
+ </li>
+
+ <li>
+ Project directory names clearly imply the purpose. SPI is for
+ service interfaces. And the implementations can be differentiated
+ with respect to their design (POJO) or the container they're
+ destined to run in.
+ </li>
+
+ <li>
+ Conformance to this pattern down the road will make configuration
+ and deployment to various containers easier to maintain and
+ fuctionality to perform these tasks may be shared.
+ </li>
+
+ <li>
+ Container Classloader heirachies can hang multiple implementations
+ under an SPI Classloader if the SPI and implementations are kept
+ separate.
+ </li>
+
+ <li>
+ A separation of concerns: those interested in a specific container
+ don't care about the wrapper implementation, setup and configuration
+ of the wrapper implementations for other containers.
+ </li>
+
+ <li>
+ One pleseant side-effect is that it makes people stop and think
+ about what they are doing in terms of service interfaces and
+ component implementations.
+ </li>
+
+ <li>
+ It makes sense to keep a subsystem's nested subsystems and its
+ services together under one directory. This way the directory
+ heirarchy models the project and service dependencies within the
+ system.
+ </li>
+
+ <li>
+ It makes sense to keep the implementations of a service interface
+ together under on umbrella directory for the service.
+ </li>
+ </ul>
+ </section>
+ </body>
+</document>
\ No newline at end of file