Domain model for team "Variants"

Acronym

team-variants-domain-model

Belongs to

Team Variants

Responsible

kruck und Duzun

History

(v1)   2021-01-13 - created initially

(v2)   2021-02-03 - updated domain model

Why is there need for such a decision?

A domain model should be created to get a better understanding of the domain.

Additional sources for better understanding the background

Evans, E. (2003). Domain-Driven Design: Tackling Complexity in the Heart of Software (1 edition). Addison-Wesley Professional.

Viable Options

• informal diagram

Alternatives not seriously considered

An informal modeling was chosen to avoid the restrictions of other diagram types.

• entity relationship diagram
• uml diagrams
  • class diagram
  • component diagram
  • etc.

How is this decision evaluated?

Additional UML-compliant diagrams can be created as the project progresses. However, it was decided that an informal model would be sufficient for initial domain coverage.

The decision was based on the available wireframes and a technical discussion. Wireframes

Resolution Details

A simplified Version of the domain model. Domain data model

Further details can be found in the wiki. Wiki

Reasons for the resolution

The model was created and further developed in an iterative process.