In my experience very few things in the business world are immutable. Dated *Role entities enhance flexibility and provide a decent audit trail for the inevitable changes that businesses need to support (I placed this order against the wrong customer, customer A has bought customer B so we need to transfer over all existing orders).
Having *Role entities alongside from/to partyIds (or any time there's multiple ways to link two objects) leads to confusion, behavioral inconsistencies and a complicated code base. For example why is there an originFacilityId on OrderHeader when there is a facilityId field on OrderItemShipGroup as well? That's just an example I noticed recently, I've noticed a bunch over the years and they only serve to complicate development. I'm sure there are scenarios where from/to partyIds are suitable (like PartyRelationship) but I disagree with a broad proposal such as this to apply them to a range of entities. I'd prefer to see us move in the other direction and remove top-level entitiy from/to fields if there is an existing *Role entity in order to simplify the datamodel while maintaining flexibility. Regards Scott On Sun, 19 May 2019 at 22:57, Pierre Smits <pierresm...@apache.org> wrote: > 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 < > slidingfilame...@gmail.com> > 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 <michael.br...@ecomify.de > > > > 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 > > > > > > > > > >
