devmentors/ddd-building-a-model

This system is a domain-driven design (DDD) exploration framework that implements an e-commerce checkout workflow. It manages the lifecycle of placing orders, including cart management, payment processing, and order validation. The codebase demonstrates various DDD patterns—such as specialized aggregates, the specification pattern for business rules, and logic fragmentation—across multiple versioned project structures. It enforces specific business constraints, such as quarterly purchase limits and payment method restrictions based on customer type.

Introduced the \PlaceOrderFromCheckoutCommand\ and its handler in both \DDD.BuildingBlocks.V8.LogicFragmentation\ and \DDD.BuildingBlocks.V9.OutOfProcDependency\. This adds the core domain logic for converting a shopping cart into a completed order, including validation for product quantity limits and quarterly purchase restrictions. The change also includes the necessary entity classes (\Order\, \OrderLine\, \CheckoutCart\, \Cart\), value objects (\Payment\, \Shipment\, \YearQuarter\), and repository interfaces/infrastructure to support the new order placement workflow.

DDD.BuildingBlocks.V8.LogicFragmentation, DDD.BuildingBlocks.V9.OutOfProcDependency · high confidence

Added a new specification pattern implementation to enforce business rules during the checkout process. This includes a \HasActiveOrderWithLimitedProductThisQuarter\ specification that prevents customers from placing orders for limited-availability products if they already have an active order for that product in the current quarter. Additionally, new \CanPayWithCash\ specifications define payment constraints for both B2B (under 20,000) and B2C (under 10,000) customer types, ensuring that cash payments are only allowed within specific value limits based on the payer type.

DDD.BuildingBlocks.V10.SpecificationUsage · high confidence

Added three new versions of the domain model to explore different aggregate design patterns. Version 5 (GraphOfObjects) introduces a monolithic Customer aggregate that manages the Cart, Checkout, and Order lifecycle, including quarterly purchase limits. Version 6 (SpecializedAggregate) refactors this into specialized aggregates, separating quarterly purchase tracking and order placement logic into dedicated classes like CustomerQuarterlyPurchases. Version 7 (AsyncBestEffort) introduces placeholder rules for asynchronous order cancellation and manual shipping checks.

DDD.BuildingBlocks.Core.V5.GraphOfObjects, DDD.BuildingBlocks.Core.V6.SpecializedAggregate, DDD.BuildingBlocks.Core.V7.AsyncBestEffort · high confidence

The solution file (DDD.BuildingBlocks.sln) was updated to include five new project references: DDD.BuildingBlocks.Core.V5.GraphOfObjects, DDD.BuildingBlocks.Core.V6.SpecializedAggregate, DDD.BuildingBlocks.Core.V7.AsyncBestEffort, DDD.BuildingBlocks.V8.LogicFragmentation, and DDD.BuildingBlocks.V10.SpecificationUsage. Additionally, the README.md was updated to add a commentary section linking YouTube videos about models, aggregates, and trade-offs, and the requirements section was modified to change the product availability limit from 'per quarter' to 'per customer per quarter' to prevent scalping.

(repo-wide) · high confidence

Added a new V10 CLI entry point that demonstrates a behavior-driven, specification-based approach to placing an order. The V10 class registers dependencies for the specification pattern, constructs a cart with a product, and processes a checkout with cash payment and B2B payer type, ultimately invoking the PlaceOrderFromCheckoutCommand handler.

DDD.BuildingBlocks.CLI · medium confidence

The project files have been updated to target .NET 7.0, moving from .NET 6.0. Additionally, the DDD.BuildingBlocks.V10.SpecificationUsage and DDD.BuildingBlocks.CLI projects now include specific package references for Microsoft.EntityFrameworkCore (versions 7.0.4 and 7.0.5), Microsoft.EntityFrameworkCore.Tools, Newtonsoft.Json, and Npgsql.EntityFrameworkCore.PostgreSQL.

(dependencies) · high confidence

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

• CAI 40 → 40 (+0.8)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 85 → 83 (-1.4)
• Architecture 98 → 98 (+0.0)
• Maturity 50 → 50 (+0.0)
• Readiness 27 → 30 (+2.7)
• Security 34 → 32 (-1.5)

• Duplicated block (26 lines × 2) (DDD.BuildingBlocks.CLI/V1.cs)
• Duplicated block (9 lines × 2) (DDD.BuildingBlocks.V10.SpecificationUsage/Core/Shared/Specifications/AndSpecification.cs)
• LLM evaluation failed
• No exposed public API
• Test reliability not measured — no test run produced results
• early-stage repository — too few commits for a meaningful bus factor
• early-stage repository — too little history to judge knowledge freshness
• git history depth insufficient
• git history depth insufficient

• CommentedOutCode (DDD.BuildingBlocks.CLI/V10.cs)
• Documentation: no installation or build instructions (README.md)
• Duplicated block (10 lines × 2) (DDD.BuildingBlocks.V10.SpecificationUsage/Infrastructure/Data/Configuration/CheckoutCartConfiguration.cs)
• Duplicated block (11 lines × 2) (DDD.BuildingBlocks.Core.V2.Encapsulated/App/OrderService.cs)
• Duplicated block (11 lines × 2) (DDD.BuildingBlocks.Core.V4.LifecycleAligned/Order/Order.cs)
• Duplicated block (11 lines × 2) (DDD.BuildingBlocks.V10.SpecificationUsage/Core/Shared/Specifications/AndSpecification.cs)
• Duplicated block (11 lines × 3) (DDD.BuildingBlocks.V10.SpecificationUsage/Core/Order/HasActiveOrderWithLimitedProductThisQuarter.cs)
• Duplicated block (12 lines × 4) (DDD.BuildingBlocks.Core.V6.SpecializedAggregate/CustomerQuarterlyPurchases/Order/Order.cs)
• Duplicated block (15 lines × 5) (DDD.BuildingBlocks.Core.V5.GraphOfObjects/Customer/Order/Order.cs)
• Duplicated block (16 lines × 2) (DDD.BuildingBlocks.V10.SpecificationUsage/Core/Shared/Specifications/AndSpecification.cs)
• Duplicated block (52–54 lines × 2) (DDD.BuildingBlocks.CLI/V1.cs)
• Duplicated block (6 lines × 4) (DDD.BuildingBlocks.Core.V6.SpecializedAggregate/Shared/YearQuarter.cs)
• Duplicated block (8 lines × 2) (DDD.BuildingBlocks.CLI/V1.cs)
• End-of-life runtime: .NET net7.0
• Members sharing a duplicated core (4 members, 50+ identical tokens) (DDD.BuildingBlocks.Core.V6.SpecializedAggregate/CustomerQuarterlyPurchases/Order/Order.cs)
• Members sharing a duplicated core (5 members, 50+ identical tokens) (DDD.BuildingBlocks.Core.V5.GraphOfObjects/Customer/Order/Order.cs)
• The collection of items within an Order is named 'Lines' in V4, V9, and V10. However, in V3, the equivalent property is named 'Product' (e.g., OrderProduct.Product or CartProduct.Product context implies singular item, but specifically Order.Order in V3 doesn't have a direct 'Lines' property listed, but OrderProduct exists. More critically, Cart.Cart uses Products in V8 and V10, while Order.Order uses Lines. The inconsistency is between Lines (Order) and Products (Cart) for the same conceptual collection of items, or potentially Lines vs Items. However, looking at Cart.Cart, V8 and V10 use Products. V3 Cart doesn't list a products property, but V5 Cart doesn't either. The main drift is Lines vs Products for collections of order/cart items. A more direct inconsistency is OrderLine vs OrderProduct. In V3, we see OrderProduct and CartProduct. In V4, V5, V6, V8, V9, V10, we see OrderLine and CartProduct (or just Product in Cart). The term for the line item in an order has drifted from OrderProduct (V3) to OrderLine (V4+).
• The property representing the street name in an order or shipment context is named Street in V1 (Order.Street), but StreetName in V2, V4, V5, V6, V8, V9, V10. This is a naming inconsistency for the same concept.
• The reference to the customer in a Cart/Checkout context is inconsistent. V3 uses a full object reference Customer (in Cart.Customer), while V5, V6, and V10 use an identifier CustomerId. While Customer vs CustomerId can be a design choice (object vs ID), the inconsistency arises because V5 Cart has CustomerId but V3 Cart has Customer. More importantly, V5 Customer class has Cart which has CustomerId, but V3 Cart has Customer. This is a semantic drift in how the relationship is modeled (Entity vs ID).
• The representation of order status is inconsistent. V1 and V3 use an OrderStatus type (enum/class). V2 uses a boolean property IsCompleted on the Order model. This is a semantic and naming inconsistency in how the state is exposed.
• …and 4 more

• Unchanged — 2 containers · 0 contexts · 0 edges

Written by watchdog.canine.dev from the codebase's own history, inside the signed delivery this page is composed from.

devmentors/ddd-building-a-model was measured the same way every project in this corpus was: the same rubric, at a pinned commit, with the result published in full. Point a surveyor at a repository you know and see whether you agree with it.