zhuravlevma/typescript-ddd-architecture

This system is a distributed logistics and accounting platform built on a microservices-style architecture using NestJS, PostgreSQL, and RabbitMQ. It manages the end-to-end lifecycle of orders, including cart management, payment processing, warehouse inventory tracking, and courier delivery coordination. The system enforces strict domain-driven design principles, utilizing sagas and outbox patterns to ensure reliable event publishing and transactional consistency across accounting, delivery, and warehouse contexts.

A new domain event, OfferTakedEvent, has been added to the board offer domain. This event is triggered when a courier accepts an offer, carrying the order ID and courier ID in its payload. This enables downstream systems to react to this specific state change in the delivery process.

src/delivery/board/offer/domain/events · high confidence

Added new libraries in src/\_\lib\\_ to support domain-driven design and architectural enforcement. The domain layer introduces DomainMessage, DomainEvent, and DomainCommand classes to structure messages with saga, correlation, and compensation metadata, alongside an Aggregate base class for managing domain messages. The architecture layer adds a file-naming validation utility (ts-arch.ts) to enforce directory and naming conventions, plus an import-dependency checker. Additionally, a DeepReadonly type utility and Entity/ObjectValues base classes with export methods are provided.

src/\\lib\\_ · high confidence_

The delivery bounded context is introduced, containing three subdomains: Board (Core), Curiers (Core), and Tracking (Supporting). The new delivery.module.ts file wires these subdomains together using NestJS dependency injection, importing the BoardModule, CuriersModule, and Tracking module into the main DeliveryModule.

src/delivery · medium confidence

A new ExternalVerificationApi class has been introduced to handle interactions with an external verification service. This class provides methods for simple and full report verification, as well as signing and completing reports, all of which are designed to interface with an external API.

src/accounting/verification/api · high confidence

Added new infrastructure modules to the application: a context module providing an async storage mechanism for request-scoped data, a correlation module that extracts or generates a correlation ID header for tracing, a RabbitMQ module for message queue integration, and a unit of work module wrapping TypeORM's EntityManager for transactional database operations.

src/\\infrastructure\\_ · high confidence_

The order management subdomain is introduced with a new README file and an \OrderManagmentModule\ that wires up domain interactor use cases (AddOrder, CreateWarehouse, UpdateOrder) to their respective in-ports and out-ports, while registering the Warehouse and Order ORM entities and the WarehouseController.

src/warehouse/order-management · medium confidence

Introduced a new relay module that implements the outbox pattern to ensure reliable publishing of domain events to RabbitMQ. The change adds a MessageOrmEntity to store outgoing messages, an OutboxMapper for data transformation, and a RelayService that periodically polls the outbox table and publishes events to specific RabbitMQ exchanges (e.g., offerTaked, orderValidated, reportValidated, orderCreated, orderCancelled, paymentCompleted, paymentFailed) or handles compensation events via the saga mechanism.

src/\\relay\\_ · high confidence_

Two new query classes, FindAllCuriersQuery and FindCurierWithCountOfOrdersQuery, have been added to the curier domain. FindAllCuriersQuery implements the FindAllCuriersInPort to retrieve all curiers, while FindCurierWithCountOfOrdersQuery implements FindCurierWithCountOfOrdersInPort to fetch a specific curier along with their order count. These changes introduce the necessary domain logic to support these specific read operations.

src/delivery/curiers/curier/domain/queries · medium confidence

Introduced new Data Transfer Objects for the accounting verification module: CreateVerificationDto and UpdateVerificationDto. The creation DTO enforces string and number types for report identifiers and status flags, while the update DTO allows optional boolean fields for completion and signing states, ensuring data integrity at the API boundary.

src/accounting/verification/dtos · high confidence

New interactors have been added to the curier domain layer to handle specific business operations: creating a new curier, adding an order to a curier, updating curier information, changing curier status, and updating order status. These new files implement the use-case logic for managing curier entities and their associated orders.

src/delivery/curiers/curier/domain/interactors · high confidence

The curier domain now includes a set of new abstract port interfaces for both input and output operations, including creating, updating, and finding curiers and orders, as well as a read model for curiers with order counts. These additions establish the domain's interface contracts for managing curier state and order associations.

src/delivery/curiers/curier/domain/ports · high confidence

Introduced the data access layer for the curier module, including ORM entities for curiers and orders, a mapper for domain/ORM conversion, and a repository implementing the out-ports for creating, finding, and saving curier and order data.

src/delivery/curiers/curier/dal · medium confidence

Introduced new REST endpoints for managing delivery offers and couriers. Users can now create, update, and retrieve offers via the /delivery/offers endpoint, including a background process that creates offers from validated reports. Additionally, the /delivery/curiers endpoint allows creating, updating, and retrieving courier profiles, as well as assigning orders to couriers and updating order statuses. The implementation includes request DTOs for validation and response DTOs for consistent API output.

src/delivery/board/offer/controllers, src/delivery/curiers/curier/controllers · high confidence

Added the CurierEntity and OrderEntity domain models, which define the structure and behavior for managing courier profiles and their associated delivery orders. The CurierEntity includes methods for adding orders, updating ratings, and managing delivery capacity, while the OrderEntity handles order states like cancellation, delivery, and tip application. A corresponding test suite was added to verify that orders can be successfully added to a courier and that attempts to exceed the order limit or perform invalid state transitions throw appropriate errors.

src/delivery/curiers/curier/domain/entities · high confidence

Introduced a new saga management system to handle distributed transaction workflows. This includes database models for tracking saga states, steps, and compensations, along with a service and controller to manage saga lifecycle, including automatic compensation triggers and timeout handling for incomplete sagas.

src/\\saga\\_ · high confidence_

Introduced new data access layer components for the warehouse domain, including TypeORM entities for warehouses and orders, a mapper for converting between domain and ORM models, and a repository implementing ports for saving, retrieving, and querying warehouse data.

src/warehouse/order-management/warehouse/dal · medium confidence

Introduced a new tracking capability for warehouse deliveries, allowing users to create and update delivery routes. The change adds a NestJS module with a controller exposing POST and PATCH endpoints for route creation and updates, a service layer that persists delivery data and updates coordinates via an external tracking API, and the corresponding data transfer objects and database model.

src/warehouse/tracking · high confidence

The repository now uses Husky to automatically run linting, formatting, and tests at key Git hooks. The pre-commit hook runs linting and formatting before changes are staged, while the pre-push hook ensures that linting, formatting checks, and all tests pass before code is pushed to the remote repository.

.husky · high confidence

Added the main accounting module that imports the Reports and Verification subdomains, alongside initial README documentation outlining the bounded context structure.

src/accounting · high confidence

The repository is initialized with essential configuration files and tooling. This includes environment variable templates (.env.example), a Dockerfile and docker-compose.yml for containerized development, and configuration for TypeScript, NestJS, Jest, ESLint, Prettier, and commitlint. These changes establish the foundational build, test, and runtime environment for the application.

(repo-wide) · high confidence

The application is initialized with a new NestJS module structure, configuring PostgreSQL via TypeORM, integrating RabbitMQ for messaging, and exposing Swagger documentation at /swagger. The entry point sets up the app with environment-based configuration for database and message broker connections, and registers multiple domain modules including Relay, Accounting, Delivery, Warehouse, Cart, and Payment.

src · high confidence

The Curiers subdomain is introduced with a new NestJS module that wires up the core delivery logic. This includes the module configuration, a README, and the implementation of key interactions such as creating and updating curiers, managing order assignments, and querying curier statuses.

src/delivery/curiers · high confidence

The Board module is introduced, wiring the Offer domain's use cases (CreateOffer, UpdateOffer) and repositories into the NestJS application. This registers the necessary controllers, providers, and TypeORM entities to support offer-related operations within the Board subdomain.

src/delivery/board · high confidence

A new Offer entity has been added to the domain model, defining the structure and behavior for delivery board offers. This includes attributes such as name, order ID, courier ID, vehicle type, preferred delivery areas, working hours, weight, and bid. The entity manages state transitions like setting vehicle type based on weight, updating bids, handling courier takeovers, and cancellation logic.

src/delivery/board/offer/domain/entities · high confidence

The accounting reports subdomain now provides full CRUD operations for managing reports. Users can create new reports triggered by order validation events, retrieve report details by ID, and update report status (validating or canceling reports). The implementation includes a new REST API controller, domain entities, repository, and interactor services that handle report persistence and business logic.

src/accounting/reports · high confidence

The cart subdomain now provides full CRUD operations for shopping carts, including creation, retrieval, and updates. A new \CartModule\ wires together controllers, interactor use cases, and repository layers. The \CartController\ exposes a POST endpoint to create a cart and handles an \OrderCancelledEvent\ via RabbitMQ to update cart state. The \CartRepository\ persists cart data to a relational database using TypeORM, while \ExternalSagaApi\ communicates with an external saga service to manage order lifecycle events.

src/cart/cart · high confidence

Added the data access layer for the Offer domain, including the Offer ORM entity, a mapper for converting between domain and ORM models, and a repository implementing the find-by-ID, find-by-order-ID, and save-offer ports. This enables the application to persist and retrieve offer data via TypeORM.

src/delivery/board/offer/dal · high confidence

Added a new tracking subdomain within the delivery context, including a Route entity, DTOs for creating and updating routes, a NestJS controller and service for managing route state, and an external API client for fetching courier coordinates. This enables users to create and update delivery routes and retrieve current position data from an external source.

src/delivery/tracking · high confidence

Added new domain-layer interfaces and implementations for offer management. The update interactor now accepts an optional courier ID to assign a courier to an existing offer, while the create interactor initializes a new offer with default values (e.g., 'bike' vehicle type, 'New York' preferred area). New ports define the contract for saving offers and finding them by ID or order ID, supporting the internal logic for offer lifecycle management.

src/delivery/board/offer/domain/interactors, src/delivery/board/offer/domain/ports · high confidence

Added a new payment subdomain within the cart module, including a Payment entity, controller, and service that listen for OrderCreated events to process payments via an external API. The service emits PaymentCompleted or PaymentFailed domain events (and corresponding saga compensation events) to track payment status, with the module wiring these components together using TypeORM and RabbitMQ subscriptions.

src/cart/payment · medium confidence

A new verification module has been added to the accounting system, introducing support for verifying subdomains. This includes a NestJS module configuration that wires up the Verification controller, service, and external API, while also importing the ReportsModule and TypeORM for data access.

src/accounting/verification · medium confidence

Users can now create, update, and manage verification records for accounting reports. The new Verification model defines the data structure including fields for completion, signing, and report association. The VerificationService implements the core logic for creating and updating verifications, including validation checks (e.g., preventing double completion or signing an already completed report) and integration with external verification APIs for full verification, signing, and completion actions.

src/accounting/verification/services · high confidence

Added new DTOs (AddOrderDto, CreateWarehouseDto, UpdateOrderDto, SavedWarehouseResponseDto) and a WarehouseController that exposes POST /warehouse/warehouses to create a warehouse, PATCH /warehouse/warehouses/:warehouseId/orders/:orderId to update an order's validity, and a RabbitMQ subscription for payment-completed events. This provides the API surface for managing warehouses and their associated orders.

src/warehouse/order-management/warehouse/controllers · high confidence

Added new domain entities for the warehouse order management system: OrderEntity, which models an order with an ID, name, and validity status, and WarehouseEntity, which aggregates multiple orders and manages their lifecycle. The WarehouseEntity includes logic to add orders (with a 500-order limit), cancel orders via saga compensation, extend order periods, and validate orders, emitting corresponding domain events (OrderValidatedEvent, SagaCompensationEvent, SagaCompletedEvent).

src/warehouse/order-management/warehouse/domain/entities · high confidence

A new controller has been added to handle verification endpoints for the accounting and delivery domains. This controller exposes POST and PATCH routes to create and update verification records, delegating logic to the existing verification service.

src/accounting/verification/controllers · medium confidence

The codebase now includes new abstract port interfaces for the warehouse domain, specifically defining input ports for adding, creating, and updating orders and warehouses, as well as output ports for retrieving warehouse data and saving warehouse entities. These interfaces establish the contracts for the application's use cases and infrastructure, enabling the implementation of order and warehouse management features.

src/warehouse/order-management/warehouse/domain/ports · medium confidence

The warehouse domain now includes new event classes, specifically ExtendOrderPeriodEvent and OrderValidatedEvent, which represent the extend order period and order validated states respectively. These events are structured to carry specific payloads (orderId, warehouseId) and are configured with context and aggregate information, enabling downstream systems to react to these specific order management milestones.

src/warehouse/order-management/warehouse/domain/events · high confidence

Added new domain interactors for managing warehouse orders: AddOrderInteractor handles adding orders via payment completion events, CreateWarehouseInteractor creates new warehouse entities, and UpdateOrderInteractor updates order statuses. These interactors implement their respective in-ports and coordinate with warehouse and order ports to persist changes.

src/warehouse/order-management/warehouse/domain/interactors · high confidence

Introduced the initial structure for the Warehouse bounded context, including a README that outlines the two subdomains (Order Management and Tracking) and a NestJS module that wires them together.

src/warehouse · high confidence

The initdb script now creates the necessary database schemas (accounting, warehouse, delivery, and public) to support the application's data layer. This ensures the database is properly initialized with the required structure before the application starts.

initdb · medium confidence

Added architectural and naming convention tests; Added unit tests for the AddOrderToCurier interactor.

The project now includes a package.json and package-lock.json that define the full set of runtime and development dependencies for a NestJS application. Runtime dependencies include NestJS core packages (common, core, platform-express), RabbitMQ client (amqplib, @golevelup/nestjs-rabbitmq), TypeORM with PostgreSQL, Swagger, scheduling, validation, and utility libraries. Development dependencies cover testing (Jest, Supertest), linting and formatting (ESLint, Prettier, @typescript-eslint), commit linting, and build tooling (TypeScript, ts-node, ts-loader, ts-morph).

(dependencies) · high confidence

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

• CAI 45 → 44 (-1.8)
• Rubric changed (rubric-2026.08.19 → rubric-2026.09.15) — scores are not directly comparable.

• Code Health 76 → 87 (+10.6)
• Architecture 48 → 55 (+7.0)
• Maturity 65 → 61 (-4.1)
• Readiness 30 → 27 (-2.8)
• Security 63 → 55 (-7.9)

• Boundary-crossing change coupling: domain-message.ts ↔ relay.service.ts (src/lib/domain-message.ts)
• Boundary-crossing change coupling: offer-taked.event.ts ↔ order-validated.event.ts (src/delivery/board/offer/domain/events/offer-taked.event.ts)
• Boundary-crossing change coupling: outbox.mapper.ts ↔ order-validated.event.ts (src/relay/outbox.mapper.ts)
• Boundary-crossing change coupling: report-validated.event.ts ↔ offer-taked.event.ts (src/accounting/reports/report/domain/events/report-validated.event.ts)
• Boundary-crossing change coupling: report-validated.event.ts ↔ order-validated.event.ts (src/accounting/reports/report/domain/events/report-validated.event.ts)
• Boundary-crossing change coupling: report.entity.ts ↔ offer.entity.ts (src/accounting/reports/report/domain/entities/report.entity.ts)
• Change coupling clique: report.controller.ts, offer.controller.ts, curier.controller.ts (src/accounting/reports/report/controllers/report.controller.ts)
• Coverage not included — suite not readable by the collector
• 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] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• …and 44 more

• Critical CVE: [GHSA redacted] (package-lock.json)
• Critical CVE: [GHSA redacted] (package-lock.json)
• Documentation: no installation or build instructions (README.md)
• Documentation: no usage examples (README.md)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• High CVE: [GHSA redacted] (package-lock.json)
• …and 71 more

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

zhuravlevma/typescript-ddd-architecture 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.