Repository files navigation

Bounded Contexts:

• Cart - Context for cart operations
  • Subdomains: -
    • Core Cart - adding items to the shopping cart
    • Generic Payment - payment for goods
• Warehouse - Context for warehouse operations
  • Subdomains: -
    • Core OrderManagement - order management at the warehouse
    • Supporting Location - management of product locations at the warehouse, product categorization
• Accounting - accounting context
  • Subdomains: -
    • Core Reports - financial reports generation
    • Supporting Verification - order verification
• Delivery - delivery context
  • Subdomains: -
    • Core Board - board of order proposals
    • Core Couriers - management of couriers
    • Supporting Tracking - delivery status tracking

This project is a large monolith structured at a high level intobounded contexts. Each context contains subdomains that, depending on the type, implement their architectural pattern. For theCore subdomain, aDomain model is chosen, while for theSupporting subdomain, eitherTransaction script orActive Record is implemented as its architectural pattern.

• Domain model: Core

  Domain model with a clean architecture with ports and adapters. It takes into account some tactical patterns from DDD.

  

• Active Record: Generic/Supporting

  Active Record uses the most obvious approach, putting data access logic in the domain object.

  

• Transaction Script: Generic/Supporting

  Transaction Script organizes business logic by procedures where each procedure handles a single request from the presentation.

  

If you have a large monolith that contains manybounded contexts, then the service can be divided into modules by context.

If you have a micro service architecture and you prefer to allocate contexts to different services (which is preferable). If it's not enough for you, then you can also divide subdomains into services.Each Core subdomain can be divided into modules byaggregates.

Firstly, we have a limitation - this is the change of one aggregate in one transaction (strong consistency). To change multiple aggregates at the same time, you need to use eventual consistency.

We cannot write a message directly to the broker, because it may not be available. PatternTransactional outbox.

Transactional outbox can be done using synchronous calls, the broker is not biased. But this option is more suitable for point-to-point communication.

In a good way, each bounded context in a micro-service architecture should have its own Relay. In the demonstration monolith, I decided to limit myself to one.

The project uses a saga with choreography and a registrar. The registrar is capable of rolling back transactions in case of failure.

This is not a production ready solution!

Utilities for convenient architectural testing (similar toArchUnit in Java) have been developed for the project. They can be executed using the command:

npm run test:arch

npm install

CREATESCHEMAIF NOT EXISTS accountingCREATESCHEMAIF NOT EXISTS warehouseCREATESCHEMAIF NOT EXISTS deliveryCREATESCHEMAIF NOT EXISTS public

cp .env.example .env

npm install

npm install dotenv-cli

dotenv npm run start:dev

cp .env.example .env

docker-compose up

# unit tests$ npm runtest# arch tests$ npm run test:arch# test coverage$ npm run test:cov