|
Modeling key concepts or business entities and their relationships clarifies the team's understanding of the problem to be solved. It allows the team to uncover subtle complexities early on, as well as to establish a common vocabulary. Use the links below for an overview. For details about a role, activity, or artifact in the diagram, click on its icon.
More detail: Purpose - How to Staff
|
|
|
|
|
| Purpose |
|
The purpose of this workflow detail is to:
- Create and validate a domain model to the extent appropriate for your project
- Capture important business rules
A domain is an area of knowledge or activity characterized by a family of related systems. The domain model is a subset of the Artifact: Business Object Model. A domain model captures the most important Artifact: Business Entity abstractions (modeled as UML classes) within the context of the domain. A domain model does not include any business worker definitions. For example, an insurance company's domain model may include classes and relationships for policy, insured, and claim.
The Role: Business Designer performs the Activity: Find Business Workers and Entities, focusing only on the entities. The most significant entities are then described in Activity: Detail a Business Entity. The domain model, business entities, and any Artifact: Business Rules defined are reviewed by the Role: Business Model Reviewer who ensures these artifacts are accurate and complete enough for subsequent work to begin.
When discussing key business entities and their relationships, important business rules are discussed. The Role: Business Process Analyst is responsible for Activity: Maintain Business Rules. A variety of methods for maintaining business rules exist; a formal or very complex project may create Artifact: Business Rules.
These activities are sometimes skipped when the project team has a good working knowledge of the project's context and key concepts.
|
| How to Staff |
|
The Role: Business Designer often leads a series of workshops with subject matter experts, Role: Business Process Analysts, Role: Requirements Analysts, and the Role: Software Architect participating. On some projects stakeholders and Role: Software Designers may also participate or observe. These workshops allow the team to define the domain model and to identify business rules. A skilled facilitator must fulfill the Business Designer role for these activities.
The Role: Business Process Analyst captures business rules. If business rules are kept within the models, then the Business Process Analyst and Business Designer collaborate on these rules.
The Role: Business Model Reviewer reviews the resulting work. At times, the Business Model Reviewer may call upon additional subject matter experts or stakeholders to assist in the review.
|
|
|
Workflow