Untitled Lesson
Skill Matrix
UNLOCK NODES BY LEARNING NEW TAGS.
Why might "Product" legitimately be modeled with completely different attributes in a Catalog bounded context versus a Shipping bounded context?
💻 Code Challenge | +75 XP
Model an Order aggregate root with a private list of OrderLine items, an addLine() method that enforces a total-recalculation invariant, ensuring external code cannot bypass it by modifying line items directly.
A bug was traced to external code directly pushing into an order's internal line-items array, bypassing the total-recalculation logic and leaving the order in an inconsistent state. Reorder the steps to fix this using aggregate boundaries.
Task: Reorder the blocks in logical sequence to solve the problem.
A.D.A. Interface
Adaptive Didactic Assistant
Pascual Vila
Frontend Instructor // Code Syllabus
The Error //
Allowing external code to directly modify an aggregate's internal collection, bypassing the aggregate root
// Wrong: bypasses the Order aggregate's invariant entirely
order.lines.push(new OrderLine(product, qty)); // total never recalculated
// Correct: goes through the aggregate root, invariant enforced
order.addLine(product, qty); // internally recalculates the totalThe Solution //
This allows business invariants the aggregate root is supposed to enforce (like keeping a total in sync with its line items) to be silently violated. The aggregate's internal state should be private, with modification only possible through methods on the aggregate root that enforce the relevant invariants.
The Error //
Trying to unify a term (like "Product") into one shared model across every bounded context in the system
// Awkward: one bloated class serving unrelated concerns
class Product { name; description; images; weightKg; hazmatClass; }
// Better: separate models, each precise within its own bounded context
// catalog/Product.js and shipping/Product.js — different, and that's fineThe Solution //
Forcing a single shared model to serve multiple, genuinely different contexts (a Catalog's marketing-focused Product versus a Shipping department's logistics-focused Product) usually produces an awkward, bloated class trying to serve purposes that don't actually belong together. Model each bounded context's version of the concept separately, even if the class name is the same.