Model A Simple CRUD Back-Office Tool
This tutorial shows when a simple CRUD model is the right choice.
Scenario
A company needs an internal supplier directory. Users create suppliers, edit contact information, archive inactive suppliers, and search by region or capability. There are no complex lifecycle rules.
Blocks
- Aggregate or record: Supplier.
- Value objects: Postal Address, Email Address, Phone Number.
- Commands: Create Supplier, Update Supplier, Archive Supplier.
- Events: Supplier Created, Supplier Updated, Supplier Archived.
- Read models: Supplier Search Result, Supplier Detail.
- Queries: Search Suppliers, Get Supplier Detail.
Rules
- Supplier name is required.
- Tax identifier must be unique when provided.
- Archived suppliers do not appear in default search results.
- Only Procurement Admin can archive a supplier.
Why This Stays CRUD
The model has useful validation, permissions, and audit events, but it does not have a rich business lifecycle. A CRUD-style generated system is likely clearer and cheaper to maintain than a forced DDD design.
Where DDD Might Begin
If the supplier process grows to include onboarding, due diligence, risk review, contract negotiation, compliance renewal, and suspension, create a richer Supplier Onboarding context. Then model commands such as Start Due Diligence, Approve Supplier, and Suspend Supplier.