Part of the point of a loosely coupled architecture like the one we
use in OFBiz is the while reduction of dependencies can be helpful to
keep things better organized, they are not necessary.
In other words when a cluster of functionality that is fairly
coherent (like the Agreement stuff) has dependencies on other things
you can still keep it all in one place, even if it results in cross-
dependencies. Of course, the other side of this is that certain parts
of things are more "core" to a certain piece but in addition may have
things that are not necessary that extend it and those can and
usually should be put in other places (which is part of the point of
the new extend-entity stuff).
Being able to keep this all together is one reason I like putting it
in the order component. It makes sense for the most common use of the
existing artifacts, plus it is a higher level component and it is
fine for it to depend on lower level things like Product, Party, and
WorkEffort.
-David
On Aug 16, 2006, at 8:00 AM, Jacopo Cappellato wrote:
To summarize:
should we only move the following two entities (and their services)
from party to product:
AgreementProductAppl
AgreementPromoAppl
and the following one from party to workeffort:
AgreementWorkEffortAppl
?
And move all the ui (and more complex services) from accounting to
order?
Jacopo
Chris Howe wrote:
I like to think of the ideal dependency structure this
way:
Party
Product
Content
Workeffort
The data layer and basic logic layer independent of
each other and everything else, utilizing ONLY itself
and the OFBiz framework. For ERP, this essentially
creates an ERP framework. No UI. These are basic
services, very simple simple-methods, etc.
In this thought experiment Agreement remains in Party
as you can have Employment Agreements, Order
Agreements, Service Agreements, Warranty Agreements?,
Content Agreements, Production Agreements, and any
number of other agreements. Again, these four would
have no UI outside of possibly something similar to
what webtools provides or the state of these
components about a year to 18 months ago. The UI
would only prove as an example of the robustness and
likely never used in production environment.
On top of that you build:
Accounting
Manufacturing
Marketing
Human Resources
Content Management
This again is your lower level data manipulation
logic. A lot of your "join" entity logic goes here. (ie *Role,
*Content, *WorkeffortAppl?)
Next tier
Order
After these three tiers you can start building
interrelated operation applications that go on top. This is where
real ERP logic goes and OFBiz actually
becomes useful in a business. You start getting user
specific, purpose driven UI. This is where most of the
backend UI begins.
After that ecommerce and pos get thrown on top as UI
applications that have very little logic of their own.
This sort of structure modularizes OFBiz and makes it
very easy to see where custom needs begin. Anyway, my two cents.
But you do need to keep in mind
employment agreements breaks any idea of moving the
agreement data model over to product or order. I'm
not sure if people's suggestions were to move the data
model, or just the UI.
