nestjslatam/ddd

This system is a NestJS-based application implementing Domain-Driven Design and CQRS patterns to manage orders and products. It provides REST APIs for creating, modifying, and tracking the lifecycle of orders and products, enforcing strict business rules through domain validation. The architecture relies on a custom DDD library for aggregate management and includes structured error handling to distinguish between client validation errors and server failures.

11 changes.

This period focused on initializing the NestJS application and establishing the core Domain-Driven Design library, including aggregate roots, validation systems, and value objects. The work involved setting up development tooling, enforcing commit standards, and integrating CQRS patterns while ensuring comprehensive test coverage for the new domain infrastructure.

10 changes.

The project implemented core product and order management modules using a Domain-Driven Design and CQRS architecture, establishing full lifecycle support for entities through aggregates, value objects, and sagas. This work included introducing structured domain validation that replaces generic server errors with specific 422 responses, ensuring data integrity at the application layer. Additionally, unified test coverage reporting was established to enforce strict quality thresholds across both unit and end-to-end suites.

Introduces a new use-case for updating a product's status (ACTIVE, INACTIVE, or DELETED) via a PATCH endpoint. The implementation includes a command handler that correctly resolves the status string to a domain enum instance, ensuring valid transitions are accepted and invalid inputs return a 400 Bad Request rather than a 500 error. It also enforces domain rules by checking the aggregate's validity before persisting changes.

src/products/application/use-cases/change-product-status · high confidence

This change introduces the application-layer use cases for creating, modifying, and canceling orders, as well as updating product details. Specifically, it adds command handlers, DTOs, and services for creating an order (with customer and shipping details), adding items to an order, changing item quantities, canceling an order, and shipping an order. It also implements the ability to update a product's name, description, and price. All write operations now validate domain rules via an \isValid\ check and throw a \BrokenRulesException\ if constraints are violated, ensuring data integrity before persistence.

(repo-wide) · high confidence

Added the application-layer components for creating products, including a DTO that enforces basic type validation (string for name/description, number for price) to ensure the global NestJS ValidationPipe correctly passes data to the handler. The new service and command handler orchestrate the creation process by instantiating domain value objects (Name, Description, Price) and the Product aggregate, checking for broken rules, and persisting the result via the repository.

src/products/application/use-cases/create-product · high confidence

The application is bootstrapped using NestJS, integrating the CQRS module and the @nestjslatam/ddd-lib for domain-driven design patterns. The entry point configures global validation pipes with custom exception handling and registers a domain exception filter to improve error reporting. Additionally, Swagger documentation is enabled at the /api endpoint to expose the API schema.

src · high confidence

The repository is initialized with essential configuration files including \.editorconfig\, \.prettierrc\, \eslint.config.mjs\ (migrating to ESLint 10 flat config), \tsconfig.json\, and \nest-cli.json\. It includes a \docker-compose.yml\ for local PostgreSQL and pgAdmin, a \.env\ template, and a \.codecov.yml\ to enforce 80% code coverage. The \CHANGELOG.md\ documents the history of the \@nestjslatam/ddd-lib\ package, highlighting the 4.0.0 release which introduced comprehensive testing and fixed several behavioral defects in the DDD library.

(repo-wide) · high confidence

The application now includes structured value objects for core domain entities: Name, Description, and Price. These objects enforce specific business rules—such as character limits, format constraints, and numeric ranges—through dedicated validators. When a value violates these rules, the system throws a BrokenRulesException, ensuring data integrity at the domain level rather than allowing invalid states to propagate.

src/shared/valueobjects · high confidence

The new products module implements a full product lifecycle using NestJS CQRS, exposing REST endpoints for creating, reading, updating, and deleting products. It enforces domain invariants through a set of validators (name, description, price, status, and business rules) and fixes a critical bug where aggregate validity guards were previously unreachable due to a mismatch between the library's \isValid\ getter and the code's property access. The module also wires up event handlers and sagas to react to product creation, price changes, and status updates, supported by an in-memory repository and comprehensive test coverage.

src/products · high confidence

A new SharedModule has been added to the src/shared directory. Currently, this module is empty, with no imports, providers, or exports configured, serving as a structural placeholder for future shared functionality within the application.

src/shared · high confidence

The \libs/ddd/src\ area now contains the foundational Domain-Driven Design (DDD) library, introducing the \DddAggregateRoot\ base class that manages identity, change tracking, and state transitions. This release adds a comprehensive validation system via \AggregateValidationOrchestrator\ (enforcing guard, business rule, and property validation stages) and \BrokenRulesManager\ (handling deduplication and reporting of validation errors). It also includes core infrastructure for aggregate identity (\AggregateIdentity\), equality comparison (\AggregateEquality\), and serialization (\AggregateSerializer\), all supported by extensive test coverage to ensure correct construction ordering and behavior.

libs/ddd/src · high confidence

A new index.ts file has been added to the libs/ddd/src/core directory, serving as the public API entry point for the core domain-driven design module. This file re-exports functionality from five internal sub-modules: tracking-state, validator-rules, business-rules, repositories, and aggregate, allowing consumers to import these features from a single location.

libs/ddd/src/core · high confidence

Added \DateTimeHelper\ and \DddObjectHelper\ classes to the DDD library, exposing static methods for UTC date truncation, timestamp retrieval, entity/value-object discrimination, plain-object serialization, and NestJS provider metadata extraction. These helpers are now exported from the \libs/ddd/src/helpers\ index and are accompanied by extensive unit tests that validate edge cases such as leap years, timezone offsets, immutability guarantees, and prototype-chain distinctions.

libs/ddd/src/helpers · high confidence

The application now supports confirming an order, marking it for delivery, and removing items from an existing order. These new use cases (ConfirmOrder, DeliverOrder, RemoveItemFromOrder) follow a consistent pattern: they locate the order via the repository, execute the domain action (confirm, deliver, or removeItem), and then validate the resulting state using the unified isValid getter on the order's broken rules. If validation fails, a BrokenRulesException is thrown with the specific rule violations; otherwise, the order is saved and domain events are committed. Each use case exposes a dedicated service and command handler, accepting DTOs that carry the necessary identifiers (orderId, and productId for item removal).

src/orders/application/use-cases/confirm-order, src/orders/application/use-cases/deliver-order, src/orders/application/use-cases/remove-item-from-order · high confidence

The \src/orders\ module now provides a complete DDD and CQRS implementation for managing orders. It exposes a REST API with endpoints for creating, retrieving, and modifying orders (adding/removing items, changing quantities), as well as transitioning orders through their lifecycle (confirm, ship, deliver, cancel). The implementation includes domain event handlers for order state changes, sagas for orchestrating complex processes, and query handlers for reading order data with filtering and pagination. The order aggregate enforces business rules such as minimum order amounts, item quantity limits, and valid status transitions.

src/orders · high confidence

A change to existing behaviour in db — 1 commit, 1 file.

db · low confidence · unverified

The repository now enforces commit message standards using Husky and Commitlint. A new \commit-msg\ hook has been added to the \.husky\ directory, which runs \npx commitlint\ on every commit to ensure messages adhere to the configured conventional commit format before they are accepted.

.husky · high confidence

The new DomainExceptionFilter replaces the previous behavior where domain validation failures (such as an invalid price) resulted in a generic 500 Internal Server Error. Client requests that violate domain invariants now receive a 422 Unprocessable Entity response, including a structured list of the specific broken rules (property, message, and severity). Other domain exceptions like missing values or invalid formats continue to return 400 Bad Request, while state transition errors return 409 Conflict.

src/shared/filters · high confidence

The application now distinguishes between server failures and client validation errors by introducing a \BrokenRulesException\. Previously, invariant violations in aggregates like Orders and Products resulted in generic 500 Internal Server Error responses, obscuring the specific rule that failed. This change allows the system to return 422 Unprocessable Entity responses that explicitly list the violated business rules (e.g., property and message), enabling clients to understand exactly what input was invalid.

src/shared/exceptions · high confidence

A new script (scripts/merge-coverage.js) merges unit and end-to-end coverage reports into a single view, ensuring that application-layer code exercised by e2e tests is no longer reported as 0% coverage. The merged report enforces its own thresholds (82% statements/lines, 78% branches, 84% functions) and fails the build if any metric falls below these floors, while existing per-suite thresholds in package.json remain unchanged.

scripts · high confidence

The NumberValueObject class, which shipped unusable in previous versions due to a constructor-order defect, is now fixed to correctly apply validation options (such as allowZero, requirePositive, allowNaN, and epsilon) by rebuilding validators after options are assigned. Additionally, the library introduces robust, tested implementations for IdValueObject (enforcing UUID v4 generation, strict format validation, and case canonicalization), StringNotNullOrEmptyValidator (supporting trimWhitespace, allowEmpty, and minLength), and NumberNotNullValidator (handling null, NaN, and Infinity with configurable allowances), ensuring that all value objects validate correctly on construction and mutation.

libs/ddd/src/valueobjects · high confidence

Added end-to-end tests for the application's write endpoints (products and orders) to verify correct HTTP status codes, input validation, and domain invariant enforcement. The tests ensure that structural errors return 400, domain violations return 422 with specific rule details, and valid requests succeed. The test suite includes a Jest configuration and setup file to properly initialize the NestJS application with validation pipes and exception filters.

test · high confidence

The application and its DDD library have been upgraded to support NestJS 11, with \@nestjs/common\, \@nestjs/core\, \@nestjs/cqrs\, and \@nestjs/swagger\ pinned to version 11.x. The \@nestjslatam/ddd-lib\ peer dependencies now accept both NestJS 10 and 11, while the library itself is published as version 4.0.0. Development tooling has also been updated, including Jest to 30.x, TypeScript to 5.9.x, and ESLint to 10.x, ensuring compatibility with Node.js 20.11+.

(dependencies) · high confidence

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

• CAI 54 → 68 (+14.7)
• Rubric changed (rubric-2026.08.18 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 81 → 86 (+5.2)
• Architecture 60 → 63 (+3.0)
• Maturity 74 → 69 (-4.9)
• Readiness 60 → 75 (+14.8)
• Security 40 → 78 (+37.7)

• Coverage not included — suite not readable by the collector
• Critical CVE: [GHSA redacted] (package-lock.json)
• Critical CVE: [GHSA redacted] (package-lock.json)
• Critical CVE: [GHSA redacted] (package-lock.json)
• Dependency hygiene not measured — dependency manifest found but not parsed for hygiene
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (libs/ddd/package-lock.json)
• …and 48 more

• Dependency advisory scan runs only on code events
• Documentation: no architecture or design documentation (docs/ci-cd-setup-checklist.md)
• Documentation: no installation or build instructions (README.md)
• High CVE: [GHSA redacted] (package-lock.json)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High IaC: WD-COMPOSE-0002 (docker-compose.yml)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• High: security finding (details withheld)
• …and 23 more

• 44 commits — 30 feature/other, 14 fixes

• (root) — 15 commits
• (repo) — 13 commits
• libs/ddd — 5 commits
• src/orders — 5 commits
• .github/workflows — 2 commits
• src/products — 2 commits
• docs/getting-started.md — 1 commit
• src/shared — 1 commit

• fix: Merge pull request #23 from nestjslatam/fix/release-workflow
• fix: Merge pull request #24 from nestjslatam/fix/uuid-esm-regression
• fix: Merge pull request #25 from nestjslatam/fix/number-valueobject-options
• fix: Merge pull request #27 from nestjslatam/fix/preserve-declaration-docs
• fix: Merge pull request #29 from nestjslatam/fix/aggregate-validity-guard
• fix: fix(build): keep JSDoc in the published type declarations
• fix: fix(ci): pin @commitlint to 20.x for Node 20 compatibility
• fix: fix(ci): rebuild the publish pipeline around tags
• fix: fix(deps): revert uuid to the dual CJS/ESM line
• fix: fix(domain): aggregate validity guards could never fire
• fix: fix(sample): drop the "multiple of 100" price rule (#33)
• fix: fix(sample): make the write endpoints work, and test that they do (#38)
• fix: fix(security): drop @nestjs/devtools-integration to clear critical advisories
• fix: fix(valueobjects): repair NumberValueObject, unusable since it shipped
• change: Merge pull request #21 from nestjslatam/chore/upgrade-nestjs-11
• change: Merge pull request #22 from nestjslatam/release/ddd-lib-2.1.0
• change: Merge pull request #26 from nestjslatam/release/ddd-lib-2.1.2
• change: Merge pull request #28 from nestjslatam/docs/readme-cli-and-ecosystem
• change: Merge pull request #30 from nestjslatam/docs/flag-stale-documentation
• change: Merge pull request #31 from nestjslatam/docs/readme-overhaul
• …and 24 more

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

nestjslatam/ddd 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.