Skip to content

Domain Model

Arda’s System manages the information, processes, and workflows to support manufacturing and material flow operations.

The system keeps information to:

  • Serve as reference for business processes and operations (e.g., a list of suppliers, items, or prices)
  • Represent the state of the operations it supports (e.g., the availability of materials, state of orders) or the resources
    used in those operations (e.g., the state or utilization of a machine or an operator)
  • State of the interactions of users or other integrated systems to implement complex workflows
  • Internal structure and state information needed to ensure correct behavior of the system itself.

This information is very complex and must faithfully represent concepts and capture details of the real-world domain it supports. In addition, some of this information must be stored in a persistent form. This means it survives system restarts and can be backed up or restored in bulk as part of system OAM. Persistent data may use different storage technologies, such as RDBMS’s or key-value stores. Regardless of the technology, the complexity of the information requires a clear description to guide the implementation of the system and for Arda’s engineers and business stakeholders to communicate unambiguously about requirements and architectural decisions.

The information model of the system is a structured description of the information the system manages. It must partition the overall information into discrete pieces that can be described independently and then combined with clear relationshiops to provide a comprehensive view of the system’s information.

Values and Entities

The system manages two distinct kinds of information contents: Values and Entities.

Values are immutable pieces of information defined by their contents and a set of equivalence rules that depend on their type (see below for a description of types). They can be stored in the system and compared to other values of the same type. See Value Types for details.

Entities have an identity and can change over time without altering their identity. Their identity is immutable and unique in the system. Two entities are never equal as such because their identities are different. The contents of an entity can be compared to the contents of other entities or other values that share the same type or structure. When comparing contents, entities should be treated as Values excluding their identity in the comparison. The immutability and uniqueness of identity, coupled with the ability to change their information contents creates the need to define the lifecycle of an entity and requirements for managing their updates (versioning, auditing, etc.). Different kinds of entities may have different lifecycles depending on business requirements and their role in the system.

Values and Entities are described using concepts from Object-Oriented Analysis and Design. In particular, we use:

  • Commonly accepted meaning and behaviors of Primitive Types and Composites
  • The concept of Entities to describe the information that is used to represent the state of the system and how it changes in response to user actions or other events.
  • Type Theory concepts to structure the relationships between entities and values. While not adhering to a strict semantic type system, we use:
    • Specialization (subtyping) to express commonality of behaviors between types.
    • Composition (product types) to express containment and part-of relationships.
    • Instantiation to express the is-a relationship between a type and its instances.
    • Reference to express access to other entities (not values) that are not part of a type internal state.
    • Genericity to express patterns of behavior that apply based on the shape of the data (values or entities) that they operate on. (e.g Lists, etc. and also constraints on the generic types to describe more specific and rich behaviors).
    • Stereotypes or common types of entities or relationships that are used multiple times in the system, like the concept of a Journalled Entity to describe entities that keep track of their changes over time.
    • Union (co-product types) to express types that can be one of several alternatives.

We mostly use UML diagrams to describe these concepts with textual annotations where needed to clarify the meaning of UML arrows.

Copyright: © Arda Systems 2025, All rights reserved

Comments