Skip to content

architecture.md

Latest commit

 

History

History
61 lines (43 loc) · 3.73 KB

architecture.md

File metadata and controls

61 lines (43 loc) · 3.73 KB
Raw

Архітектура LifeOS

Проєкт LifeOS побудований на принципах Domain-Driven Design (DDD) та Hexagonal Architecture (Ports and Adapters). Це забезпечує гнучкість, тестованість та незалежність бізнес-логіки від зовнішніх факторів (бази даних, Telegram API тощо).

🏗️ Шари архітектури

1. Domain Layer (Ядро)

Розташування: internal/domain/

Це найважливіший шар, який містить бізнес-правила та сутності. Він не має жодних зовнішніх залежностей.

  • Сутності (Entities): Мають унікальний ID та стан, що змінюється (напр., Note, Task, Habit). Поля зазвичай приватні, доступ тільки через методи.
  • Об'єкти-значення (Value Objects): Immutable об'єкти без ID, визначаються своїми атрибутами (напр., Priority, Status).
  • Інтерфейси репозиторіїв: Визначають, як домен взаємодіє з базою даних (без реалізації).

2. Application Layer (Сценарії використання)

Розташування: internal/application/

Цей шар координує виконання задач. Він використовує доменні об'єкти для реалізації бізнес-логіки.

  • Commands: Дії, що змінюють стан (Create, Update, Delete).
  • Queries: Дії, що тільки повертають дані (List, Search).
  • DTOs: Об'єкти для передачі даних між шарами.

3. Infrastructure Layer (Реалізація)

Розташування: internal/infrastructure/

Містить технічні деталі та реалізацію інтерфейсів репозиторіїв.

  • Persistence: Реалізація репозиторіїв для SQLite.
  • External: Клієнти для зовнішніх API (напр., Weather).
  • Scheduler: Планувальник для нагадувань.

4. Interfaces Layer (Взаємодія)

Розташування: internal/interfaces/

Точка входу для користувача. В нашому випадку — це Telegram бот.

  • Handlers: Приймають повідомлення від Telegram, викликають Application layer та повертають відповідь.
  • Middleware: Авторизація, логування, обробка помилок.

🧱 Структура каталогів

internal/
├── domain/               # Бізнес-логіка (Entities, VOs, Interfaces)
│   ├── user/
│   ├── note/
│   ├── task/
│   ├── habit/
│   └── finance/
├── application/          # Use Cases (Commands, Queries)
├── infrastructure/       # Зовнішні деталі (DB, API, Scheduler)
└── interfaces/           # Telegram Adapters

📜 Основні принципи розробки

  1. Незалежність від фреймворків: Бізнес-логіка не повинна залежати від бібліотеки Telegram.
  2. Тестованість: Завдяки портам та адаптерам, будь-яку частину можна протестувати за допомогою моків.
  3. Чіткі межі (Bounded Contexts): Нотатки, Задачі та Фінанси розділені на рівні логіки.