One of the most eye-opening events for me was learning about Color-Based Modeling. It totally transformed my approach to designing systems.
The key idea is that there are four archetypes in object-oriented design:
- Moment-Interval represents an event, or a span of time. For instance applying for a loan is a Moment the entire process from application to closure of the loan would be an Interval
- Role represents participants in a Moment-Interval. Sticking with the loan, an Applicant would be one role, the loan officer would be another, underwriters would be a third.
- Descriptor represents a label or a "class" of objects. For example, you might have a descriptor for Home Loans versus Auto Loans but the loans themselves are fundamentally the same. The Descriptor can also act as a factory. I usually use descriptors where people normally use Enums.
- Person/Place/Thing represents a physical, tangible object. Michael Brown is a person, Global Corp. Headquarters is a Place, Dell Precision Laptop with serial number 12345 is a thing. (Note my specific Dell Precision Laptop would possibly have a descriptor attached to it in Dell's E-commerce system).
Those are the 4 basic elements of an O-O model. And here is how it relates to your question.
The very first archetype is the Moment-Interval. If you recall one of the guidelines for basic object-oriented programming "Objects are Nouns, Methods are Verbs" you might be tempted to represent the loan application as a method "ApplyForLoan" on the Applicant object and store all the information about the application on a single Loan object. Then you might be tempted to have a "LoanStatus" enumeration on the Loan that basically lists all the phases the loan goes through as it's being processed.
The better way is to have an Application moment object. And an Applicant role object. Roles are attached to Person/Place/Thing and participate in moments (in practice, I usually give the responsibility for creating a Moment object to a Role that I identify as the "actor". In the case of the loan application the Applicant is the "actor".
Within the book, Coad talks about the concept of Predecessors and Successors. I.e. before a RiskAssessment can be performed, there must be an Application. The Moments form a chain of events that are pertinent to the system being created. For instance the loan approval system would not care about payments on the loan so they wouldn't be mapped as part of the system. Although there might be another system that does deal with these details.
The beautiful part of this approach is that the system becomes very flexible and extensible because rather than sticking new fields and methods on a bloated "LoanCustomer" object (or worse deriving from loan customer to represent different roles the customer might play in the system), we create new roles as the needs of the system grows.
I'd HIGHLY recommend picking the book up and going through it. It's a very powerful technique despite the fact that UML is no longer in favor, the concepts are timeless.