ofbiz-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Warnock <mwarn...@ridgecrestherbals.com>
Subject Re: Compoinent locatinos was Contributor branch Proposal,
Date Wed, 21 Jul 2010 00:52:14 GMT
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.  

Matt Warnock <mwarnock@ridgecrestherbals.com>
RidgeCrest Herbals, Inc.

On Tue, 2010-07-20 at 17:11 -0700, BJ Freeman wrote:
> Matt:
>   from a users perspective it would not be any different.
> However from a developers perspective, if the manufacturing is of no 
> use, like in a retail outlet, then it should be able to be  deactivated 
> with no ill effect to the base applications.
> Matt Warnock sent the following on 7/20/2010 2:47 PM:
> > +1.
> >
> > Our company sits right at the intersection of two industries,
> > distribution and manufacturing.  We outsource our manufacturing, but we
> > still have to manage it quite a bit, and ordering more product requires
> > printing approved labels, etc.  So in some ways we look more like a
> > distributor/warehouse with a very small number of SKUs, and in others
> > more like a rather simple manufacturing operation.
> >
> > Silverston does a great job of laying out what both the manufacturing
> > and distribution business models should include.  But I don't need to
> > use most of either one.  At some point (far in the future) we may use
> > more of the manufacturing.  But having the shared data in the entities
> > means I don't need to worry about whether the distribution set will talk
> > properly to the manufacturing set, and whether the database structure
> > that I use now will integrate properly later on as our needs may change.
> >
> > I probably would not use most of the features of either a distribution
> > or manufacturing special-purpose app in its entirety, but seamless
> > integration of both is critical to me.  That's why David's model of
> > keeping the data structure entities in the core is important, IMHO.
> >
> > I don't (and probably never will) use time billing, job costing, or POS
> > features at all, but it certainly doesn't bother me that the data
> > structures are defined in the core for those whose models will include
> > those common functions.
> >
> > Just my 2 cents.
> >

View raw message