32.6. NextGen POS Conceptual Class Hierarchies
Payment Classes
Based on the above criteria for partitioning the Payment class, it is useful to create a class hierarchy of various kinds of payments. The justification for the superclass and subclasses is shown in Figure 32.7.
Figure 32.7. Justifying
Payment subclasses.[View full size image]
Authorization Service Classes
Credit and check authorization services are variations on a similar concept, and have common attributes of interest. This leads to the class hierarchy in Figure 32.8.
Figure 32.8. Justifying the AuthorizationService hierarchy.
[View full size image]
Authorization Transaction Classes
Modeling the various kinds of authorization service transactions (requests and replies) presents an interesting case. In general, transactions with external services are useful to show in a domain model because activities and processes tend to revolve around them. They are important concepts.Should the modeler illustrate every variation of an external service transaction? It depends. As mentioned, domain models are not necessarily correct or wrong, but rather more or less useful. They are useful, because each transaction class is related to different concepts, processes, and business rules.[5]
[5] In telecommunications domain models, it is similarly useful to identify each kind of exchange or switch message.
A second interesting question is the degree of generalization that is useful to show in the model. For argument's sake, let us assume that every transaction has a date and time. These common attributes, plus the desire to create an ultimate generalization for this family of related concepts, justifies the creation of PaymentAuthorizationTransaction .But is it useful to generalize a reply into a CreditPaymentAuthorizationReply and CheckPaymentAuthorizationReply, as shown in Figure 32.9, or is it sufficient to show less generalization, as depicted in Figure 32.10?
Figure 32.9. One possible class hierarchy for external service transactions.
[View full size image]