https://github.com/msolorio/allocation_service

Backend API for allocating customer orders to batches of stock in a warehouse using patterns from domain driven design.
https://github.com/msolorio/allocation_service

Last synced: 3 months ago
JSON representation

Backend API for allocating customer orders to batches of stock in a warehouse using patterns from domain driven design.

• Host: GitHub
• URL: https://github.com/msolorio/allocation_service
• Owner: msolorio
• Created: 2024-03-20T17:08:03.000Z (over 1 year ago)
• Default Branch: main
• Last Pushed: 2024-11-04T03:56:08.000Z (8 months ago)
• Last Synced: 2025-02-10T22:52:24.069Z (5 months ago)
• Language: Python
• Homepage:
• Size: 248 KB
• Stars: 1
• Watchers: 1
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md

Awesome Lists containing this project

README

        
# Allocation Service

Backend API for allocating customer orders to batches of stock in a warehouse.

### Stack

- Python

- PostgreSQL

- Flask

- SqlAlchemy

- Docker

---

### Architecture

The application uses the [dependency inversion principle](https://en.wikipedia.org/wiki/Dependency_inversion_principle), and creates abstractions around I/O and injects them. This allows us to pass a fake I/O to the service layer for testing the application "edge-to-edge" with fast, in-memory unit tests.

![in-memory-implementation](README_assets/in-memory-implementation.png)

---

For real-world and E2E testing, the service layer is passed real I/O that talks to a database. Because we have already exhaustively tested the service layer with fast, in-memory tests, less slow E2E tests are needed. We can achieve a healthy testing pyramid with high coverage.

![e2e-implementation](README_assets/e2e-implementation.png)

---

A few patterns are used to aid dependency inversion.

**Repository** - an abstraction around data access. Handles syncing between the domain model and the ORM.


**Unit of Work** - an abstraction around transactions and atomicity.


**Service Layer** - the entrypoint for injecting I/O and defines the application's use cases.


**Domain Model** - an object module of the business domain free of dependencies on data access.


**Data Mapper** - handles conversion between domain objects and db objects.


**Trade-offs** - Each pattern adds indirection and congintive load and wouldn't be necessary in a simple application. You could, for example, still achieve dependency inversion and abstracting I/O with only a simple repository and a service layer.