nandi.uk
This repository has no description
1# Directory Structure
2
3This document outlines the project's directory structure, designed to support a layered architecture based on Domain-Driven Design (DDD) principles.
4
5## Top-Level Structure
6
7```
8.
9├── docs/ # Project documentation (like this file, domain model)
10├── lexicons/ # Lexicon definition files (.json)
11├── src/ # Source code
12│ ├── annotations/ # Bounded Context: Annotations
13│ ├── atproto/ # Bounded Context: AT Protocol specifics
14│ ├── lexicon/ # Generated lexicon types and utilities
15│ └── main.ts # Application entry point (e.g., server setup)
16├── test/ # Automated tests
17├── .gitignore
18├── package.json
19├── tsconfig.json
20└── ... # Other configuration files
21```
22
23## Bounded Context Structure (`src/<context>/`)
24
25Each bounded context (e.g., `src/annotations`, `src/atproto`) follows a layered architecture:
26
27```
28src/<context>/
29├── application/ # Application Layer: Use cases, DTOs, ports/interfaces
30│ ├── use-cases/ # Application services orchestrating domain logic
31│ ├── dtos/ # Data Transfer Objects for API boundaries
32│ ├── repositories/ # Interfaces (Ports) for data persistence
33│ └── ports/ # Interfaces (Ports) for other infrastructure (e.g., publishing, external APIs)
34├── domain/ # Domain Layer: Core business logic, entities, value objects
35│ ├── aggregates/ # Aggregate roots and associated entities
36│ └── value-objects/ # Domain value objects
37└── infrastructure/ # Infrastructure Layer: Persistence, external services, etc.
38 ├── persistence/ # Data persistence implementation (e.g., ORM, database clients)
39 └── services/ # Clients for external services (if any)
40```
41
42## Reasoning
43
44- **Bounded Contexts:** Top-level directories under `src/` (`annotations`, `atproto`) clearly separate distinct domain areas, reducing coupling and improving clarity.
45- **Layered Architecture:** The `domain`, `application`, and `infrastructure` subdirectories within each context enforce separation of concerns.
46 - **Domain:** Contains the core business logic, independent of how it's used or stored.
47 - **Application:** Orchestrates use cases, acting as a bridge between the domain and infrastructure/UI. Defines interfaces (Ports) needed from infrastructure (e.g., repositories, publishers).
48 - **Infrastructure:** Handles technical details like databases, external APIs, etc., implementing interfaces (Adapters) defined in the application layer.
49- **Dependency Rule:** Dependencies flow inwards: Infrastructure depends on Application, Application depends on Domain. The Domain layer has no dependencies on outer layers.
50- **Organization:** Further subdivision within layers (e.g., `use-cases`, `aggregates`, `value-objects`, `repositories`, `ports`) keeps related code together.
51- **Scalability:** This structure makes it easier to add new features, modify existing ones, or even swap out infrastructure components (Adapters) without impacting the core domain logic, as long as the Ports (interfaces) are respected.
52- **Lexicon Separation:** The generated `src/lexicon` types are kept separate, acting as a shared kernel or potentially part of the ATProto context's interface, depending on how they are used.
53
54This structure aims for clarity, maintainability, and testability by enforcing clear boundaries and responsibilities.