@zigrivers/scaffold 2.1.2 → 2.38.0

package/knowledge/core/domain-modeling.md

@@ -4,6 +4,8 @@ description: Domain-driven design patterns for identifying and modeling project
 topics: [ddd, domain-modeling, entities, aggregates, bounded-contexts, domain-events, value-objects]
 ---
 
+## Summary
+
 ## Strategic DDD Patterns
 
 Strategic DDD operates at the system level, answering where domain boundaries fall and how domains communicate.
@@ -54,6 +56,8 @@ Not all parts of a system are equally important or complex. Classify domains by
 
 **Classification decisions matter because they drive resource allocation.** Over-investing in a generic domain (building a custom auth system when Auth0 exists) wastes effort. Under-investing in a core domain (using a generic CRUD framework for your competitive advantage) produces mediocre software.
 
+## Deep Guidance
+
 ## Tactical DDD Patterns
 
 Tactical DDD patterns structure the code within a bounded context.
@@ -315,3 +319,7 @@ A domain model is likely correct when:
 - **Cross-context communication is explicit.** No context reaches into another's internals. All integration goes through documented mechanisms (events, APIs, shared language).
 - **The model explains the business.** A new team member can read the domain model and understand what the business does, what its rules are, and how its parts interact.
 - **Value objects outnumber entities.** Most concepts in a well-modeled domain are values, not identities. If nearly everything is an entity, you may be confusing data containers with identity-bearing objects.
+
+## See Also
+
+- [task-decomposition](../core/task-decomposition.md) — DDD entities map to implementation tasks