I totally agree with leave the entity designs well designed and solid
The Unified Data Model has been designed well and is still withstanding the test of time. This design is the reason why our project opted to have this at its core for all the business applications. It is the digressions from (even more so the explanation regarding the applicability of those digressions) that have us going through hoops to ensure that what is used where, when, how and why remains consistent. From persistence, through service/functions and UI to documentation. Best regards, Pierre Smits *Apache Trafodion <https://trafodion.apache.org>, Vice President* *Apache Directory <https://directory.apache.org>, PMC Member* Apache Incubator <https://incubator.apache.org>, committer *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges) since 2008* Apache Steve <https://steve.apache.org>, committer On Sun, May 19, 2019 at 11:46 AM Taher Alkhateeb <[email protected]> wrote: > I'm also in favor of the more flexible design based on roles. Let the > services worry about sorting this stuff out and leave the entity > domain layer solid and well designed. > > On Thu, May 16, 2019 at 11:25 PM Michael Brohl <[email protected]> > wrote: > > > > Hi Pierre, > > > > I think there are more sophisticated concepts for some of the mentioned > > entities, for example > > > > - OrderRole for orders allows to connect an unlimited number of parties > > with different roles > > > > - CustRequestParty, QuoteRole, CustRequestRole - same principle > > > > For these, introducing from/toPartyId would be no improvement IMO. *If* > > we would want to make a change, I would tend more to implementing the > > ...Role principle where it is missing and get rid of the from/toPartyId > > pattern. But this would be a big change... > > > > I'm not sure why we have these in some entities which also have the > > ...Role entities, such as Invoice. > > > > Maybe others can give more insights? > > > > Regards, > > > > Michael Brohl > > > > ecomify GmbH - www.ecomify.de > > > > > > Am 13.05.19 um 13:41 schrieb Pierre Smits: > > > Hi All, > > > > > > Currently several entities capture the (contractual) parties in fields > like > > > fromPartyId and toPartyId. These parties commonly represent the > internal > > > (accounting) organisation and the external party (the customer, > supplier, > > > contact, account, carrier etc). > > > > > > Such entities are: > > > > > > - Agreement (in party) > > > - Employment (in humanres) > > > - Invoice (in accounting > > > - OrderReportPurchasesGroupByProduct > > > - PartyBenefit (in humanres) > > > - Payment (in accounting) > > > - PayHistory (in humanres) > > > - ReturnHeader (in Order) > > > - UnemploymentClaim (in humanres > > > > > > > > > However there are a (quite a) few entities that defy these 1-on-1 > > > relationships (between internal party and the object, and the external > > > party and the object), like: > > > > > > - OrderHeader: neither partyIdFrom nor partyIdTo > > > - Quote: neither partyIdFrom nor partyIdTo but having a partyId > field > > > - CustRequest: only having fromPartyid (plus its role > > > - Subscription: having originatedFromPartyId (plus the role) and > partyId > > > - ReorderGuideline: having partyId (plus the role) > > > > > > And I am confident I am missing a few. > > > > > > In oder to simplify processes for capturing the main parties in various > > > entity records I propose to realign these (master) entities to ensure > that > > > both the primary internal and external parties (and their primary > roles) > > > are captured. > > > > > > What are your thoughts? > > > > > > Best regards, > > > > > > Pierre Smits > > > > > > *Apache Trafodion <https://trafodion.apache.org>, Vice President* > > > *Apache Directory <https://directory.apache.org>, PMC Member* > > > Apache Incubator <https://incubator.apache.org>, committer > > > *Apache OFBiz <https://ofbiz.apache.org>, contributor (without > privileges) > > > since 2008* > > > Apache Steve <https://steve.apache.org>, committer > > > > > >
