Modelling Individuals and Organizations
I'm developing an application where a user can either act as an individual, or as a member of an organization, and I'm having some trouble modelling this so support the various systems.
To explain the rules, users log in and peform actions, but these actions may be in their own name, or performed on behalf of their organization. An individual can only peform the former, while a member of an organization can act on their own behalf or on behalf of their organization. A user can only be a member of a single organization.
And to clarify, an organization is a different beast than an individual. Primarily because it isn't a different type of individual, but instead a collection of individuals that operates as an independent identity in the system. It also supports a range of member-management functionality (payroll, for example) because of that. While it doesn't do anything itself, since it's members perform actions for it, it is the organization that is considered to have performed the action when the dust settles.
So now much of the objects within the system can have a parent that is either an individual or an organization, and several UI screens apply to both scenarios equally, with very minor differences (sometimes with no difference at all).
This leads to a host of implementation details. Let's say both individuals and organizations can buy widgets as one of many actions they both share. Now we must support the concept of widgets belonging to either an individual or an organization. Business logic must be able to handle both scenarios, ideally with minimal duplication, and persistence has to take into account that the parent relationship of widgets isn't bound to a single type, but one of two (individuals or orgs). Most of the systems in the application must deal with this issue.
I know this is a very abstract question, but I'm at an abstract phase of the design. Has anyone dealt with this type of model, and what techniques have been used to architect it?
Thanks to everyone in advance!
[2071 byte] By [
nanjoutaia] at [2007-10-2 2:29:42]
Interesting. And obvious (doh... ;) But then patterns always feel that way.
Designing the Party pattern in the domain layer seems pretty logical. As for the relational side of the coin, I could break it into 4 tables, Parties, Individuals, Organizations, and Widgets. The latter three could all reference the Party table, and now I've eliminated issues with overlapping/ambiguous identity values in the database.
Nice!
> Interesting. And obvious (doh... ;) But then
> patterns always feel that way.
>
> Designing the Party pattern in the domain layer seems
> pretty logical. As for the relational side of the
> coin, I could break it into 4 tables, Parties,
> Individuals, Organizations, and Widgets. The latter
> three could all reference the Party table, and now
> I've eliminated issues with overlapping/ambiguous
> identity values in the database.
I think you'll need some others. There's a many-to-many relationship between Individuals and Organizations.
> Nice!
Can be complex. I've seen it done badly. I don't think Party is necessarily trivial, even if the idea is simple.
%
> I think you'll need some others. There's a
> many-to-many relationship between
> Individuals and Organizations.
True enough. I already have an object representing the relationship and attributes related to it (date, role, etc).
> Can be complex. I've seen it done badly.
> I don't think Party is necessarily trivial, even
> if the idea is simple.
Certainly isn't trivial. All sorts of new issues arrise. For example, with the proposed table layout, Parties, Individuals, and Organizations all have different ID's, and that needs to be reconciled.
Situations arise where your working with a system that references Parties, but you want to access more detailed information about the Person or Organization, perhaps for display purposes. Now you have to figure out how to get the derived type with just a Party ID. Doable, but I'd prefer to avoid a blind search through the Person and Organization tables.
What if the Party table referenced the sub-type? Perhaps a column that maps to an enum in code such as PartyType.Person and PartyType.Organization. Mappers like Hibernate could use this information to automatically create an object of the derived type when you load a Party.
Anyone know of any open-source Java or .NET projects that solve these problems? I'd love to see code.
