my orginal statement that got this part of the thread going was
>ofbiz, now has three basic layers, as I see it.
>
> first is the framework, which should stand alone from the other layers.
>
> Next is your basic Business layer needed for all businesses, to
manage relationships, cash flow, products. This level can have
interdependence and dependence on the framework.
>
> the top layer is the type of business one has, manufacturing,
Ecommerce, Travel. these don't really depended on each other, unless you
have a multidivisional organization and are driven by different Business
plans as to how to implement.
>
Matt Warnock sent the following on 7/20/2010 5:52 PM:
I understand that. But Dave's point (if I understood his post
correctly) was that the separation into modules was in fact made at the
application level, not the database level. All the entities, their
storage mechanisms, and data translation code for those, are defined in
the base.
Keeping the database layer intact in the base reduces the likelihood of
incompatible design and interface between competing and/or cooperating
modules. The user interface is easy to change, but keeping the database
design 1) monolithic and 2) close to Silverston serves to keep the whole
project design cohesive. I think those goals are more important than
complete modularity.
Of course, there could be a solid middle ground, where the entities are
defined in the base, but only actually *created* if the modules that use
them are being built. That way a DBM administrator would not have to
rifle through empty tables. However, that might also tempt people to
assume what tables are or are not in use, and make conflicting design
decisions. This at least forces people to understand the
Silverston-based OFBiz best practices model.
