References Overview

Purpose

The Reference section contains cross-cutting definitions and rules that apply across the entire Nimbo WMS domain and all warehouse processes.

While:

• Domain describes what exists,
• Processes describe what happens,

the Reference section defines:

• how things must behave consistently,
• which rules are universal,
• which concepts are shared everywhere.

It acts as the contract layer of the system.

---

Scope of Reference

The Reference section covers concepts that are:

• reused by multiple entities and processes,
• fundamental to correctness and consistency,
• not owned by a single domain entity or process.

These rules are global, not process-specific.

---

Reference Topics

Inventory Statuses

Defines the set of allowed inventory states for InventoryItem.

Purpose:

• describe physical and operational availability of stock,
• control which operations are permitted.

Inventory statuses are:

• shared across all processes,
• strictly separated from document statuses,
• governed by a formal state machine.

---

Inventory Status State Machine

Defines allowed transitions between inventory statuses.

Purpose:

• prevent illegal state changes,
• ensure predictable stock behavior,
• encode warehouse reality into domain rules.

The state machine:

• is enforced at domain level,
• applies only to InventoryItem,
• must be respected by all processes.

---

Units of Measure (UoM)

Defines how quantities are represented and converted.

Purpose:

• ensure consistent quantity handling,
• avoid ambiguity and rounding errors,
• normalize stock to a single base unit per item.

UoM rules apply to:

• inventory storage,
• inbound, outbound, and transfer documents,
• quantity validation and calculation.

---

Naming Conventions & Domain Invariants

Defines:

• shared naming rules,
• global invariants that must always hold true.

Purpose:

• establish a ubiquitous language,
• protect data integrity,
• prevent accidental domain violations.

Invariants apply across:

• entities,
• processes,
• persistence layer.

---

Why Reference Is Separate

Reference content is separated because it:

• does not belong to a single entity,
• does not describe a workflow,
• must remain stable as the system evolves.

This separation:

• reduces duplication,
• simplifies reasoning,
• makes rules explicit and discoverable.

---

Enforcement Philosophy

Reference rules must be enforced by:

• domain services,
• application logic,
• validation layers.

They must not rely on:

• UI behavior,
• database side effects,
• developer convention alone.

Violations must:

• fail explicitly,
• leave the system unchanged,
• produce clear business errors.

---

Reference as a System Contract

The Reference section represents the non-negotiable contract of Nimbo WMS.

Any future extension must:

• comply with existing reference rules, or
• explicitly extend them in this section.

If a process or feature cannot be expressed without breaking a reference rule, the domain model must be revisited.

---

Summary

The Reference section:

• anchors the system’s behavior,
• unifies domain and processes,
• ensures long-term consistency.

It is the final authority on how Nimbo WMS behaves, regardless of implementation details.