Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/zhuravlevma/typescript-ddd-architecture
Typescript DDD architecture for nest.js with saga, subdomains, clean architecture, domain model, aggregates, event-driven ⚡
https://github.com/zhuravlevma/typescript-ddd-architecture
aggregates architecture clean-architecture ddd ddd-architecture domain-driven-design domain-model event-driven event-driven-architecture eventbus example javascript nestjs node-js nodejs rabbitmq saga saga-pattern typeorm typescript
Last synced: about 23 hours ago
JSON representation
Typescript DDD architecture for nest.js with saga, subdomains, clean architecture, domain model, aggregates, event-driven ⚡
- Host: GitHub
- URL: https://github.com/zhuravlevma/typescript-ddd-architecture
- Owner: zhuravlevma
- License: mit
- Created: 2023-04-25T17:49:38.000Z (over 1 year ago)
- Default Branch: main
- Last Pushed: 2025-01-07T21:12:11.000Z (14 days ago)
- Last Synced: 2025-01-14T01:07:25.267Z (8 days ago)
- Topics: aggregates, architecture, clean-architecture, ddd, ddd-architecture, domain-driven-design, domain-model, event-driven, event-driven-architecture, eventbus, example, javascript, nestjs, node-js, nodejs, rabbitmq, saga, saga-pattern, typeorm, typescript
- Language: TypeScript
- Homepage: https://learning.oreilly.com/library/view/learning-domain-driven-design/9781098100124/
- Size: 987 KB
- Stars: 125
- Watchers: 4
- Forks: 5
- Open Issues: 7
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# DDD patterns with examples
## Marketplace Domain
### Event Storming schema
### Describe
**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
### Module boundaries
This project is a large monolith structured at a high level into [bounded contexts](https://martinfowler.com/bliki/BoundedContext.html). Each context contains subdomains that, depending on the type, implement their architectural pattern. For the **`Core subdomain`**, a [Domain model](https://martinfowler.com/eaaCatalog/domainModel.html) is chosen, while for the **`Supporting subdomain`**, either [Transaction script](https://martinfowler.com/eaaCatalog/transactionScript.html) or [Active Record](https://www.martinfowler.com/eaaCatalog/activeRecord.html) is implemented as its architectural pattern.
- **`Domain model: Core`**
[Domain model](https://martinfowler.com/eaaCatalog/domainModel.html) with a clean architecture with ports and adapters. It takes into account some tactical patterns from DDD.
- **`Active Record: Generic/Supporting`**
[Active Record](https://www.martinfowler.com/eaaCatalog/activeRecord.html) uses the most obvious approach, putting data access logic in the domain object.
- **`Transaction Script: Generic/Supporting`**
[Transaction Script](https://martinfowler.com/eaaCatalog/transactionScript.html) organizes business logic by procedures where each procedure handles a single request from the presentation.
If you have a large monolith that contains many [bounded contexts](https://martinfowler.com/bliki/BoundedContext.html), 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 by [aggregates](https://martinfowler.com/bliki/DDD_Aggregate.html).
### Why do I need an event bus?
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.
### Why do I need Relay?
We cannot write a message directly to the broker, because it may not be available. Pattern [Transactional outbox](https://microservices.io/patterns/data/transactional-outbox.html).
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.
### Saga
The project uses a saga with choreography and a registrar. The registrar is capable of rolling back transactions in case of failure.
#### Calling for compensation
#### Timeout compensation
### Important
This is not a production ready solution!
### ArchUnit
Utilities for convenient architectural testing (similar to [ArchUnit in Java](https://www.archunit.org/)) have been developed for the project. They can be executed using the command:
```bash
npm run test:arch
```
## Installation
```bash
npm install
```
## Running the app (local)
```sql
CREATE SCHEMA IF NOT EXISTS accounting
CREATE SCHEMA IF NOT EXISTS warehouse
CREATE SCHEMA IF NOT EXISTS delivery
CREATE SCHEMA IF NOT EXISTS public
```
```bash
cp .env.example .env
```
```bash
npm install
```
```bash
npm install dotenv-cli
```
```bash
dotenv npm run start:dev
```
## Running the app (docker)
```bash
cp .env.example .env
```
```bash
docker-compose up
```
## Test
```bash
# unit tests
$ npm run test
# arch tests
$ npm run test:arch
# test coverage
$ npm run test:cov
```