Skip to content
EN FR

Applying the Method to the party Package

Documentation status: guide — see Maturity and evidence.

Ontological position

The party package belongs to the foundational level. Its responsibility is not to list actors from a particular sector, but to provide a stable representation of any entity that can play a role, enter a relationship, be identified, be contacted, or participate in other business structures.

Party is the root concept. Structural specializations such as NaturalPerson and LegalEntity can distinguish person-specific and organization-specific attributes, but business roles remain separate concepts.

Model a role as an autonomous concept. A person is not intrinsically a learner, employee, or guardian; a party plays a role in a context. PartyRole therefore carries the party, role type, optional context, validity period, and other role semantics.

Relationships with their own meaning should not be reduced to scattered foreign keys. PartyRelationship can represent direction, type, validity, source documentation, and source/target roles.

Typical supporting concepts include:

  • PartyIdentifier;
  • ContactPoint;
  • Address;
  • PartyClassification;
  • PartyStatusHistory.

Core invariants

Examples of domain invariants include:

  • a party has a stable identity and coherent status;
  • an active primary identifier is unique within its issuing scheme;
  • a primary role of the same type and context is not duplicated over overlapping validity periods;
  • an active relationship references valid parties according to the historical rules of the model;
  • a primary contact point is unique per relevant usage type when required.

These invariants belong to the domain. Persistence constraints may reinforce them but must not be the only place where their meaning exists.

Domain events

Stable events can include party creation, role assignment, relationship creation, identifier addition or verification, contact-point changes, and status changes. Events should expose integration semantics without leaking the full internal aggregate representation.

Technical projection

The conceptual structure can be projected into model files and persistence facets. Collections should expose roles, relationships, identifiers, and contact points without bypassing business actions.

Typical actions include AssignRole, LinkParty, AddIdentifier, AddContactPoint, and ChangeStatus. Each action should document preconditions, invariants, history behavior, and published events.

Extension discipline

Do not add every project-specific specialization directly to party. Sector packages should extend or specialize the foundational concepts. This is the main mechanism that preserves reuse and prevents the foundational package from becoming a container for local requirements.