Objectives
Customer and Supplier are arguably two of the most common entities of business concern, and their symbolic description is bound to reflect the different rationales driving domain modelling. First among them is the distinction between who’s involved and what’s the deal.
Assuming that a given party may be both a customer and a supplier, the objective is to consolidate the financial commitments while managing the specifics of the different deals independently.
Persistency Layer
Based on the Party pattern, suppliers and customers are described by independent entities with delegation to parties (sub-typing is not an option as it would contradict the Liskov Substitution Principle and put the external consistency at risk).
An abstract base class is introduced for party roles and used to keep tabs on roles history. Position is a derived entity identified by party, with Payments and Invoices derived independently as Payments do not necessarily reference a single invoice.
Since the semantics of abstraction and inheritance often differ between languages, it may be safer to distinguish between objects identification and supported aspects. For instance, a party in a barter may safely inherit from role for its identification, and from supply and consume for its behavior.
The main benefit of such a description is that it captures all requirements information without constraining the options open to the designers. It may also enhance the traceability between requirements and design patterns, in that example by explicitly mapping aspects to facades.
In any case it must be reminded that models necessary reflect a specific point of view. For example, from the taxman perspective Order will probably be a concrete class with attributes for buyers and suppliers.
Application Layer
Based on patterns for actors and access rights, use cases for Sales, Purchases, and Accounts can be described using a service oriented perspective.
