Application/Repository structure

There are two issues at play here. First, there is the overall supplier

pattern. The simple structure you have described makes a lot of sense, and

follows the reccomendations consistently made throughout Forte materials.

The one extension I would make is to break apart services into "Policy" and

"Persistence" layers, which would become plan groups, like the "Windows"

and "Business Objects". Also, you will probably want to have multiple

projects for each layer, but the overall supplier pattern would look like

this:

-> means "supplies"

Biz -> Windows

Biz -> Policy

Biz -> Persistence

Persistence -> Policy

Policy -> Windows

Persistence -> Windows (This one gets some arguments that it makes an

application 2-tier.)

DB Library -> Persistence

Display Library -> Windows

So what would go in each group? A good example would be the Stock Trade

application from the Intro training class. With the exception that there

is only one services project, the supplier pattern is the same as the one

shown above. If you were to distinguish between Policy and Persistence,

then the TraderManager would be Policy, and the CustomerService would be

Persistence.

As for the multiple applications within a single development repository:

Don't do it. I have seen the results of this approach, and they are not

pretty. Your repository will bloat, your developers will have access to

more code than they need, people will modify things that they should not,

and there will be a single bottleneck for development of all applications.

An integrate by one developer will prevent all other developers from

updating during the (longer) integrate.

Instead, I reccomend an approach akin to supplier plans. Your 3 groups of

classes could be described as:

1. Enterprise Wide Components

2. Domain Components

3. Application Implementation

I recommend 3 groups of repositories for these components. There should be

one repository for components that are system wide, one repository for each

domain, and one repository for each application. The code from one layer

will be included in a lower layer, either through code import or

(preferably) a library. That way, code would be distributed from higher

layers, but not modified in lower layers. One idea behind this is that

components of the first type would change rarely. Once determined, core

business classes, basic windows, and the like may change, but not very

often. The second layer may change more frequently, and the third layer

will likely be quite volatile. For each repository at the top 2 levels,

there should be one senior developer who determines what changes are made,

when they are made, and how the changes are distributed. This gatekeeper

metaphor may sound dogmatic and inflexible, but it prevents headaches.

Also, most of the administration can be automated.

The one revision to this would be use of reference partitions. The reason

for this is that reference partitions require that object ids (maintained

internally by Forte) match between the referencer and the referenced. In

that case, you should use the deployment repository to make sure that

object ids are in sync.

All of this looks at lot better on a white board or in a good free-form

presentation tool.

Let me know if you have any questions.

Regards

CSB

At 02:52 PM 2/3/98 GMT, MARK NICHOLS wrote:

>Hello All -

>

>I am curious if anyone has developed an approach to housing multiple

applications within a single repository. Our first production Forte projet

resulted in over 20 Forte Projects each with it's own collection of

supplier plans. Obviously we are in danger of having circular reference

problems and when we compile service objects we get client code included

from the supplier plan links.

>

>With the advent of our second project we are feeling that this stucture

needs some major revamping. We have undertaken an initiative to restructure

this application so that it exists in three Forte projects only: one each

for Windows, Objects and Services. The supplier plan links are also hugely

reduced: Windows are supplied by Services or Objects, and Services are

supplied by Objects.

>

>What we are trying to come to grips with is, a structure to allow future

development initiatives to fit into this structure easily. Our current

feeling is that we need to have three layers of these 3 projects within our

deveopment repository. The topmost layer in our repository would house the

enterprise wide objects that are common to all types of applications. The

middle layer would house windows, services, and objects common to an

application type. For example: all workflow applicaitons might inherit from

workflowWindows, workflowObjects, and workflowServices; while a payroll

application and a personnel application would inherit from hrWindows,

hrObjects, and hrServices; sharing those objects that were common to both.

The final layer of this stucture would be the distributable applications

(IE PayrollApp, PersonnelApp, WorkflowApp), which would inherit from the

middle layer.

>

>How does this idea compare with what other people have done or ar doing?

Are we headed off into the right direction? Are there any white papers on

this subject specific to Forte?

>

>Thanks

>

>

>--

>/\/\ark /\/ichols

>Senior Consultant, MSF&W Inc., Springfield, Illinois

>voice: (217) 524-1774 vmail: (217) 698-3535 x 421

><aid9f21@dpa084r2.state.il.us> <mnichols@msfw.com>

>

>Views expressed are mine unless otherwise noted.

>--

>"We have met the enemy, and they are us!" - Pogo

>

>

>

>

>

>

--

Curtis Bragdon, Senior Consultant, Forte Software

curtisb@forte.com

Voice Mail: (510) 986-3807

Paging: (888) 687-6723

"I've seen dozens of triggering towns." - Richard Hugo

at 2007-6-29 9:22:23 >