Assisting enterprises in learning, exploring, reengineering, and implementing component-based/object-oriented software solutions using best-in-class methods.

Okay, you, your team, company, is about to start a project. You've identified your problem. Well, you think you have. Chances are, your problem is about the "use of technology" and it is not really a business problem. That is, it's more of a the technologists' problem to get into new technologies. But that's not what this discussion is about; I thought I'd just throw that in for good measure. But regardless of whatever you're attempting solve, you probably started somewhere down in the tactical layer. Particularly if it's about applying some new technology.

So that brings us to the thrust of this discussion, which is the reason we do anything at all for that company that pays us at appropriate intervals. It better be for the company's bottom-line and not for another line for your resume.

One of the benefits of being involved in the system development biz a couple of decades is that I've had the benefit

The above is an extreme simplification. However, the fundamental concept is the Account. The Account is the primary tool for managing business. It is the instrument that accrues historical information. It is the Account's state (status) that a business cares about. For example, one part of the business may define ANY party with an Account where the Role of the Account is Customer. Another part of the same business may define a Customer as any Party with an Account where the Role is Customer and the status is Active.

Use Fowler's Accountability Pattern to provide further refinements, e.g. restricting what a Role can do - Purchase. Also, Locations may be associated with the Account rather than the Party. For example, one Account's Billing Address may be X while another Account's Billing Address is Y.