Skip to main content

​
Introduction

Soft-Bee API is built using Clean Architecture and Domain-Driven Design (DDD) principles, creating a maintainable, testable, and scalable Flask REST API for beekeeping management.
Clean Architecture ensures that business logic remains independent of frameworks, databases, and external services.

​
Core Principles

The architecture follows these fundamental principles:

Separation of Concerns

Each layer has a specific responsibility and doesn’t know about layers above it

Dependency Inversion

Dependencies point inward - business logic never depends on infrastructure

Feature-Based Structure

Code is organized by business features, not technical layers

Testability

Business logic can be tested without databases or external services

​
Architecture Layers

The application is organized into three main layers:
1

Domain Layer

Contains business entities, value objects, domain events, and business rules. This is the heart of the application.Location: src/features/{feature}/domain/
2

Application Layer

Orchestrates business logic through use cases. Contains DTOs, interfaces, and application services.Location: src/features/{feature}/application/
3

Infrastructure Layer

Implements technical concerns like database access, external services, and API endpoints.Location: src/features/{feature}/infrastructure/ and src/features/{feature}/presentation/

​
Feature-Based Organization

Each feature is self-contained with its own domain, application, and infrastructure code: 
src/features/
└── auth/
    ├── domain/           # Business entities and rules
    ├── application/      # Use cases and DTOs
    ├── infrastructure/   # Database and external services
    └── presentation/     # API endpoints and schemas
This structure makes it easy to understand, maintain, and scale individual features independently.

​
Key Benefits

Business logic doesn’t depend on Flask or any other framework. You could switch to FastAPI or Django without changing core business rules.
Domain entities and use cases can be tested without starting a database or web server.
Database implementations can be swapped (e.g., PostgreSQL → MongoDB) without changing business logic.
Each layer has well-defined responsibilities, making the codebase easier to understand and maintain.

​
Application Flow

Here’s how a typical request flows through the application:
  1. Presentation Layer receives HTTP request and validates input
  2. Use Case orchestrates business logic
  3. Domain Entities enforce business rules
  4. Repository handles data persistence
  5. Response flows back through the layers

​
Next Steps

Clean Architecture Details

Deep dive into the three layers and their responsibilities

Project Structure

Detailed breakdown of the directory structure

Dependency Injection

Learn how dependencies are managed and injected

Getting Started

Start building with Soft-Bee API

Build docs developers (and LLMs) love

Get started for freeTalk to us