v1.0.0 78 глав 12 разделов

Типобезопасный домен: Гексагональная архитектура на базе Effect

Подробное руководство по реализации Гексагональной архитектуры на TypeScript с использованием библиотеки Effect-ts. Вы научитесь применять систему слоев и контекстов для создания надежных приложений с идеально изолированной бизнес-логикой и типобезопасными зависимостями

typescript functional-programming architecture effect fp

Начать читать

В этой главе мы разберем, почему интуитивный подход к разработке неизбежно приводит к «вязкости» кода и росту технического долга. Вы научитесь распознавать симптомы архитектурной деградации и поймете, почему без строгих границ масштабирование проекта превращается в борьбу за выживание.

Coupling и Cohesion

Два фундаментальных свойства, определяющих качество архитектуры. Мы разберём полный спектр coupling — от патологического Content до идеального Data — и полный спектр cohesion — от случайного Coincidental до целевого Functional. Вы научитесь диагностировать проблемы по коду и увидите, как Effect-ts делает coupling явным через систему типов.

Направление зависимостей

Dependency Inversion Principle — не абстрактное правило из учебника, а конкретный механизм, определяющий всю структуру проекта. Мы перевернём наивную модель «сверху вниз», разберём правило «всё указывает внутрь» и покажем, как R-канал Effect делает нарушения невозможными на уровне компилятора.

Цели архитектуры: тестируемость, заменяемость, эволюционность

Архитектура — не самоцель, а средство достижения конкретных эксплуатационных свойств. Мы определим три главные цели — тестируемость без инфраструктуры, заменяемость адаптеров одной строкой, эволюционность без каскадных изменений — и покажем, как защитить их автоматическими fitness functions в CI/CD.

Упражнения Модуля 1

Практические задания на закрепление: идентификация видов coupling и cohesion по фрагментам кода, анализ графа зависимостей, вычисление цикломатической сложности и рефакторинг, проектирование файловой структуры Todo-приложения с нуля.

Обзор архитектурных стилей 6 глав

Классическая слоистая архитектура

Самый распространённый архитектурный стиль — Presentation → Business → Data. Мы разберём его механику, поймём почему он стал стандартом индустрии, и увидим его фундаментальные ограничения: транзитивные зависимости, «утечку» инфраструктуры вверх и невозможность заменить нижний слой без каскада изменений.

Clean Architecture (Uncle Bob)

Концентрические круги Роберта Мартина: Entities → Use Cases → Interface Adapters → Frameworks. Разберём ключевые идеи — Dependency Rule, разделение на политики и механизмы, границы между слоями — и оценим, как Clean Architecture повлияла на индустрию и где она избыточна.

Onion Architecture (Palermo)

«Луковая» архитектура Джеффри Палермо: Domain Model в центре, Domain Services, Application Services и Infrastructure на внешнем кольце. Разберём её отличия от Clean Architecture, концепцию инверсии инфраструктуры и почему она ближе всего к Hexagonal по духу.

Сравнительная таблица архитектурных стилей

Ставим все четыре подхода — Layered, Clean, Onion, Hexagonal — рядом и сравниваем по единым критериям: направление зависимостей, роль домена, механизм изоляции, тестируемость, сложность внедрения. Выявляем общее ядро идей и принципиальные различия.

Почему Ports & Adapters — лучший выбор для Effect

Кульминация модуля: почему именно Hexagonal Architecture естественно ложится на Effect-ts. Структурное соответствие Context.Tag = Port, Layer = Adapter, R-канал = Dependency Rule — это не метафора, а прямое отображение. Мы покажем, что Effect-проекты уже являются гексагональными, даже если авторы об этом не знают.

Упражнения Модуля 2

Классификация архитектурных решений из реального кода: определите стиль, найдите нарушения, предложите миграцию. Сравнительный анализ двух проектов с разными архитектурами. Проектирование Todo-приложения в каждом из четырёх стилей для наглядного сравнения.

Hexagonal Architecture — теория 7 глав

Оригинальная статья Кокберна: разбор и интерпретация

Разбор статьи Алистера Кокберна 2005 года: исторический контекст, три ключевых тезиса, влияние на Clean/Onion Architecture и DDD. Пять распространённых заблуждений и соответствие концепций механизмам Effect-ts.

Анатомия гексагона: Application Core как центр

Три зоны гексагона: Application Core, порты, адаптеры. Иерархия ядра: Domain Model → Domain Services → Application Services. Принцип нулевых зависимостей, R-канал как декларация зависимостей, файловая структура и метрики здоровья архитектуры.

Порты: контракты между ядром и внешним миром

Порт как типизированный контракт через Context.Tag. Пять свойств хорошего порта, Driving vs Driven порты, гранулярность и ISP, «скрытые» порты (Clock, IdGenerator), контрактное тестирование.

Адаптеры: реализации портов для конкретных технологий

Адаптер как Layer в Effect-ts. Driving-адаптеры (HTTP, CLI) и Driven-адаптеры (Repository, Mailer). Три обязанности: маппинг данных, ошибок, управление ресурсами. Жизненный цикл, мемоизация, паттерн адаптер-декоратор.

Driving (Primary) vs Driven (Secondary): направление потока

Driving — внешний мир управляет приложением; Driven — приложение использует внешний мир. Полный поток от HTTP до SQLite. Асимметрия реализации, множественные адаптеры, типичные ошибки смешения направлений.

Правило зависимостей: всё указывает внутрь

Зависимости исходного кода направлены только к Application Core. DIP как механизм разворота, R-канал и never как формальное доказательство. Типы нарушений, автоматизация проверки через ESLint, связь с Clean Architecture и SOLID.

Упражнения: нарисуй гексагон для своего проекта

Шесть практических упражнений: идентификация зон, определение портов, рефакторинг, построение диаграммы, классификация компонентов, проектирование приложения. Развёрнутые решения и чеклист самопроверки.

Hexagonal на диаграммах 5 глав

Визуальное мышление: от абстракции к конкретике. Канонические диаграммы, потоки данных, структура проекта и антипаттерны.

Каноническая диаграмма: порты, адаптеры, ядро

Анатомия канонической диаграммы гексагональной архитектуры — три концентрических зоны (Application Core, Ports, Adapters), направление зависимостей, симметрия левой и правой сторон, маппинг на Effect-ts концепции (Context.Tag = Port, Layer = Adapter, R-channel = Dependency Rule). Вложенные гексагоны для масштабирования.

Поток данных: запрос от HTTP до БД и обратно

Полный жизненный цикл запроса POST /api/todos через все слои — HTTP Adapter → Driving Port → Application Service → Domain Model → Driven Port → SQLite Adapter и обратно. Трансформация типов на каждой границе, карта маппинга (DTO → Input → Entity → Row → Response), поток ошибок между слоями.

Структура проекта: как гексагон отражается в файловой системе

Эталонная файловая структура гексагонального проекта на Effect-ts — domain/, ports/, application/, adapters/, composition/. Детальный разбор каждой зоны с правилами импортов, соглашения об именовании, граф зависимостей между папками, масштабирование через модульную структуру (Bounded Contexts), автоматизация проверки зависимостей через ESLint и скрипты.

Маппинг: HTTP → Port → UseCase → Port → SQLite

Полный компилируемый пример Todo-приложения — от доменных Value Objects (TodoTitle, Priority, TodoStatus) и Entity (Todo), через порты (TodoRepository, CreateTodoUseCase), Application Service, SQLite-адаптер с маппером (todoToRow/todoFromRow), HTTP-адаптер с DTO, до Composition Root и точки входа. Проверка заменяемости: SQLite → InMemory за одну строку.

Антипаттерны: утечка инфраструктуры в домен

11 антипаттернов нарушения гексагональных границ — прямой импорт инфраструктуры, типы привязанные к формату БД, HTTP-типы в домене, ORM-сущности как доменные модели, HTTP-коды в ошибках, бизнес-логика в адаптерах, бог-контекст, фреймворк-зависимый домен, инфраструктура в событиях, транзитивные зависимости, конфигурация в домене. Чеклист обнаружения и скрипт автоматической проверки.

Доменная модель — основы 6 глав

Сердце гексагона: бизнес-логика без зависимостей

Доменная модель: что в ней живёт, а что — нет

Определение доменной модели, её место в Hexagonal Architecture, полный разбор элементов домена (Entity, Value Object, Aggregate, Event, Error, Service), таблица принадлежности элементов к слоям, анемичная vs богатая модель, эвристики определения границ домена

Чистота домена: нулевые зависимости от инфраструктуры

Принцип нулевых зависимостей, паттерны загрязнения домена (прямой импорт, утечка типов, глобальное состояние, побочные эффекты), как Effect-ts обеспечивает чистоту через R-канал и E-канал, допустимые зависимости, структурное обеспечение чистоты (tsconfig, ESLint, архитектурные тесты, отдельный package.json), Dependency Inversion в домене, обработка времени и случайности, чеклист чистоты

Типы домена: Entity, Value Object, Aggregate, Event

Подробный разбор каждого типа доменных объектов: Entity (идентичность, жизненный цикл, изменяемое состояние), Value Object (равенство по значению, неизменяемость, самовалидация), Aggregate (граница согласованности, корень, единица персистентности), Domain Event (прошедшее время, неизменяемость, данные), Domain Service (межагрегатная логика), Domain Error (бизнес-нарушения). Матрица выбора типа, сравнительная таблица Entity vs Value Object

Ubiquitous Language: язык домена в типах TypeScript

Концепция единого языка из DDD, код как документация, принципы именования (имена из домена, тип выражает ограничение, доменные перечисления, операции как бизнес-действия, ошибки как бизнес-нарушения), построение глоссария для Todo-домена, паттерны именования для Entity/VO/Events/Errors/Services, антипаттерны именования, эволюция языка, практика «от разговора к типам»

Домен Todo: первая модель — Task, Status, Priority

Полная практическая реализация доменной модели Todo: Value Objects (TodoId, TodoTitle, TodoDescription, Priority, TodoStatus, DueDate), Todo Entity с командами (complete, archive, changePriority, rename, setDueDate) и запросами (isOverdue, isActive, canBeCompleted), доменные ошибки (TodoNotFound, InvalidStatusTransition, DuplicateTitle), доменные события (TodoCreated, TodoCompleted, TodoArchived, TodoRenamed, TodoPriorityChanged), доменные сервисы (фильтрация, сортировка, статистика, валидация уникальности), структура файлов, barrel file, тесты домена

Упражнения: определи границы домена для Todo

Практические упражнения: классификация домен/инфраструктура, определение типов доменных объектов, поиск нарушений чистоты, расширение модели (категории, тэги), рефакторинг с Ubiquitous Language, проектирование домена с нуля (библиотека)

Effect Schema для домена 7 глав

Schema как инструмент доменного моделирования

Почему Schema — фундамент доменного моделирования. Проблема множественных определений. Schema как Single Source of Truth. Двойственная природа Type/Encoded. Schema в контексте гексагональной архитектуры. Parse don't validate. Schema как контракт порта.

Базовые схемы: String, Number, Boolean и их рефайнменты

Строковые схемы и рефайнменты (длина, паттерн, trim, lowercase). Числовые схемы (int, positive, between, finite). Boolean и трансформации. Литеральные типы и перечисления. Nullable/Optional. Date, BigDecimal. Кастомные рефайнменты через filter. Коллекции: Array, Tuple, Record. Union. Аннотации.

Schema.Struct vs Schema.Class: моделирование сущностей

Schema.Struct — структуры данных, вложенные структуры, optional поля. Schema.Class — классы с идентичностью, номинальная типизация, методы, Smart Constructors. TaggedStruct и TaggedClass. Наследование через extend. Рекурсивные типы. Когда Struct, а когда Class.

Branded Types: TodoId, UserId — типобезопасные идентификаторы

Проблема примитивной одержимости. Brand как номинальная типизация. Schema.brand — рефайнмент + метка. Полный набор идентификаторов домена. Brand для Value Objects. UUID как Branded Type. Множественные Brand. Brand.nominal. Конверсия между типами. Модуль идентификаторов. Типобезопасность в Map/Set и Domain Events. Нулевой runtime overhead.

Композиция схем: pipe, extend, pick, omit

pipe — последовательное уточнение. extend — расширение структуры, миксины. pick — выбор подмножества полей. omit — исключение полей. partial/required — изменение опциональности. compose — цепочка трансформаций. Union — объединение схем. Паттерн CRUD-схемы из одного определения. Система фильтрации.

Decode/Encode: трансформация на границах слоёв

Базовые операции Decode (sync, Either, Effect) и Encode. Schema.transform — кастомные двунаправленные трансформации. Schema.transformOrFail. Трансформации на границах гексагона: HTTP→Domain, Domain→SQLite, Domain→Response. Обработка ParseError. Форматирование ошибок (Tree, Array). Маппинг ParseError→Domain Error. Decode с опциями.

Упражнения: создай полную Schema для Todo-домена

Практические задания: базовые доменные типы, Value Objects, Entity через Schema.Class, Domain Events через TaggedClass, CRUD-схемы через композицию, Transform для SQLite-адаптера, полная интеграция Decode→UseCase→Encode.

Value Objects — неизменяемые значения с бизнес-правилами 7 глав

Value Object: что это и зачем

Определение и характеристики Value Object. Structural equality, иммутабельность, самовалидация, заменяемость. Сравнение с Entity и Primitive Obsession. Value Objects в функциональном программировании и в контексте гексагональной архитектуры. Паттерны создания и анти-паттерны.

Реализация Value Objects через Schema.Class и Brand

Все инструменты Effect для создания VO: Schema.brand для branded примитивов, Schema.Class для составных VO, Data.Class для легковесных VO, Data.TaggedEnum для перечислений, Schema.Literal для фиксированных множеств. Паттерн Smart Constructor. Разница между new и decode. Рецепты для Simple, Composite и Enumeration VO.

Пример: Email как Value Object с валидацией

Пошаговое построение production-ready Email VO. Нормализация (trim, lowercase), валидация RFC 5322, branded type. Операции: getLocalPart, getDomain, isCorporate, mask. Интеграция с доменной моделью, портами и HTTP-адаптером. Полный набор тестов.

Пример: Money — составной Value Object

Каноничный составной VO. Хранение в minor units для точных вычислений. Currency как отдельный VO. Арифметика: add, subtract, multiply, divide с типизированными ошибками. Аллокация с распределением остатка. Schema-трансформация major↔minor units на границах слоёв. Паттерны Percentage, Price vs Cost vs Revenue.

Равенство Value Objects: Equal trait из Effect

Проблема ссылочного равенства в JavaScript. Equal trait — интерфейс структурного сравнения. Hash trait — спутник Equal, контракт equal→same hash. Автоматический Equal в Data.Class и Schema.Class. Глубокое сравнение вложенных VO. Branded types и ===. Паттерны сравнения: прямое, в условиях, поиск в массиве. Тестирование Equal-контракта (рефлексивность, симметричность, транзитивность).

Value Objects в коллекциях: HashMap с кастомным Equal/Hash

Проблема нативных Set/Map с Value Objects. HashMap и HashSet из Effect — коллекции с поддержкой Equal/Hash. Полный API: создание, чтение, модификация, итерация. Практические паттерны: индекс по VO, кеш с VO-ключами, уникальные теги, подсчёт частот, группировка. Иммутабельность и structural sharing. Интеграция с Effect Stream.

Упражнения: TodoTitle, Priority, DueDate как Value Objects

Практические упражнения по созданию Value Objects для Todo-приложения. TodoId (branded UUID), TodoTitle (нормализованная строка), Priority (литеральное перечисление с весами и операциями), DueDate (дата с операциями isOverdue, daysUntil). Эталонные решения с полными тестами. Интеграционный пример сборки Todo Entity из VO. Чеклист правильного Value Object.

Entities: объекты с идентичностью и жизненным циклом 7 глав

Entity vs Value Object: идентичность имеет значение

Фундаментальное различие между Entity и Value Object. Идентичность как непрерывность объекта во времени. Три вопроса для определения типа доменного объекта. Entity в контексте Hexagonal Architecture — нулевые зависимости, ядро бизнес-логики, работа через порты.

Реализация Entity через Schema.Class с Id

Полный паттерн реализации Entity в Effect-ts: Branded Types для идентификаторов, Schema.Class для структуры, Equal/Hash для равенства по идентичности, фабричный метод create, Schema.TaggedClass для tagged unions, Encoded форма для сериализации на границах слоёв.

Инварианты Entity: бизнес-правила внутри сущности

Три уровня защиты инвариантов: типы данных, Branded Types, Schema.filter. Конструктивные гарантии vs защитные проверки. Паттерны инвариантов: временные, state machine, бизнес-ограничения, вычисляемые. Типизированные ошибки нарушения инвариантов. Инварианты vs валидация.

Поведение Entity: методы как чистые функции

Функциональный подход к Rich Domain Model: поведение как (Entity, params) → Effect<Entity, Error>. Четыре категории поведения: конструкторы, мутаторы, переходы состояний, запросы. Namespace паттерн, pipe-композиция. Границы — что НЕ принадлежит Entity.

Жизненный цикл: create → update → complete → archive

Entity как конечный автомат (FSM). Три подхода к реализации: единый тип с runtime-проверками, Tagged Union с compile-time гарантиями, Phantom Types. Сравнение подходов. Temporal паттерны и метки времени. Связь с Domain Events.

Todo Entity: полная реализация с инвариантами

Production-ready реализация Todo Entity: Value Objects, Branded Types, Schema.Class, Equal/Hash, фабричный метод, guards, переходы состояний, мутация атрибутов, кросс-полевые инварианты, Encoded форма, barrel file, примеры использования, чеклист.

Упражнения: расширь Todo Entity новыми правилами

Семь практических заданий нарастающей сложности: добавление тегов, reopen-переход, приоритетные правила, Entity User, связь между Entity, Tagged Union подход, Property-Based Testing.

Доменные ошибки: типизированные ошибки как часть бизнес-логики 7 глав

Ошибки — часть домена, а не инфраструктуры

Философский фундамент доменных ошибок. Три категории ошибок (Domain, Application, Infrastructure). Dependency Rule для ошибок. Expected vs Defect. Почему Effect-ts — идеальный инструмент. Принципы проектирования и антипаттерны.

Data.TaggedError: доменные ошибки как tagged unions

Синтаксис и механика Data.TaggedError. Tagged Union и exhaustiveness checking. Структурное равенство (Equal и Hash). Интеграция с Effect (fail, catchTag, mapError). Сравнение с class Error, Data.TaggedClass, Schema.TaggedError. Паттерны создания: smart constructors, группировка, вложенные причины.

Иерархия ошибок: Domain → Application → Infrastructure

Три слоя ошибок в гексагональной архитектуре. Правила пересечения границ. Трансформация ошибок на границах (mapError, catchTag, catchTags, catchAll, orDie). Error Boundary через типы. Полный поток ошибки через все слои. Defects и когда их использовать. Организация файлов ошибок.

Schema для ошибок: сериализация и десериализация

Schema.TaggedError: ошибки с поддержкой encode/decode. Encode в JSON для API, Event Store, логирования. Decode с валидацией. Union Schema для множества ошибок. Практические сценарии: HTTP API, Event Store, inter-service. Генерация тестовых данных через Arbitrary. Версионирование ошибок. Выбор между Data.TaggedError и Schema.TaggedError.

Композиция ошибок: Effect.mapError, catchTag, catchAll

Автоматическое объединение ошибок в union. Полный справочник операторов: mapError, mapBoth, catchTag, catchTags, catchAll, catchSome, orElse, orElseSucceed, orElseFail, orDie, tapError, tapErrorTag, retry. Практические паттерны: Adapter Error Boundary, Use Case Error Pipeline, HTTP Error Handler, Error Enrichment, Graceful Degradation.

Ошибки Todo: TodoNotFound, InvalidTransition, DuplicateTitle

Полная production-ready модель ошибок для Todo-домена. 8 ошибок с контекстом, message, Schema. Статусная машина и валидация переходов. Бизнес-правила для заголовков, дат, приоритетов, лимитов. HTTP-маппинг. Полный пример создания задачи со всеми проверками. Unit-тесты для каждой ошибки.

Упражнения: полная модель ошибок для Todo-домена

7 практических упражнений: создание новых ошибок, композиция в Use Case, HTTP error mapper, catchTag pipeline, Schema round-trip тесты, Adapter Error Boundary, property-based тест для статусной машины.

Aggregates — Граница транзакционной согласованности 7 глав

Aggregate: кластер объектов с единой границей

Что такое Aggregate в DDD, зачем он нужен, граница транзакционной согласованности, анатомия агрегата (Root, Child Entity, Value Object), пять правил Вона Вернона, жизненный цикл и связь с Repository. Первый взгляд на реализацию через Effect-ts.

Aggregate Root: единственная точка входа

Роль Aggregate Root как привратника агрегата, глобальная vs локальная идентичность, четыре правила (все операции через корень, внешние ссылки только на корень, Repository работает с корнем). Паттерны Guard Methods, Factory Method, With-pattern. Версионирование и оптимистичная блокировка.

Защита инвариантов: правила внутри агрегата

Классификация инвариантов (атрибутные, межатрибутные, коллекционные, состояния, агрегатные). Пять стратегий защиты: Make Illegal States Unrepresentable, Smart Constructors, Validate on Mutation, Guard Methods, Assertions. Каталог инвариантов для Todo, связь инвариантов с Domain Events и тестированием.

Проектирование агрегата: размер, границы, связи

Золотое правило маленьких агрегатов. Пять эвристик определения границ: истинный инвариант, транзакционная необходимость, жизненный цикл, конкурентный доступ, размер коллекции. Пошаговый процесс проектирования, матрица принятия решений, связи между агрегатами только по ID, рефакторинг границ.

Реализация Aggregate через Effect: иммутабельный подход

Философия Aggregate как чистой функции (State, Command) → Effect<(NewState, Events), Error>. Полная реализация: Value Objects, Domain Errors, Domain Events, Child Entity, Aggregate Root с Guard Methods, Factory, Commands и Queries. Паттерн Event Accumulation. Использование в Application Layer. Тестирование.

TodoList Aggregate: список задач как единица согласованности

Полная production-ready реализация TodoList Aggregate для сквозного проекта: от бизнес-требований до barrel exports. 8 бизнес-правил, 8 операций, 8 событий, 0 инфраструктурных зависимостей. Проверка архитектурной чистоты: R=never, иммутабельность, типизированные ошибки.

Упражнения: спроектируй границы агрегатов

Практические задания: определение границ агрегатов для блога и интернет-магазина, реализация ShoppingCart с инвариантами, рефакторинг мутабельного кода в Aggregate, проектирование по бизнес-правилам, расширение TodoList новыми возможностями.

Repository Pattern: порт для персистентности агрегатов 7 глав

Repository: коллекция агрегатов в памяти (абстракция)

Объяснение репозитория как абстракции коллекции агрегатов. Ментальная модель Map<Id, Aggregate>. Отличие от DAO, Active Record. Ключевые характеристики: один Repository = один Aggregate Root, upsert-семантика save, Option для findById, идемпотентный delete. Правила проектирования и место Repository в жизненном цикле агрегата.

Repository как Driven Port: интерфейс через Effect.Service

Repository как Secondary (Driven) Port в Hexagonal Architecture. Пошаговое построение порта: доменные типы → ошибки → Context.Tag (Port) → использование в Application Service → Layer (Adapter) → Wiring. R-канал как compile-time Dependency Rule. Несколько адаптеров для одного порта. Антипаттерны: инфраструктурные типы, SQL, mutable state в контракте.

Контракт Repository: find, save, delete, findAll

Детальный разбор четырёх фундаментальных операций Repository. Сигнатуры, семантика, обоснование решений для каждого метода. Почему save возвращает void, почему findById возвращает Option, почему delete идемпотентен. Типизация ошибок, инварианты контракта (roundtrip, идемпотентность), batch-операции, расширение контракта доменными методами.

Generic Repository: параметризованный базовый контракт

Решение проблемы дублирования через параметризацию типов. Базовый интерфейс Repository<A, Id>, ограничения типов (Identifiable). Generic InMemory-фабрика, Generic SQL-фабрика. Композиция через расширение: CrudRepository → QueryableRepository → BatchRepository. Когда НЕ использовать Generic Repository. Антипаттерны: God Repository, чрезмерное абстрагирование.

Specification Pattern: гибкие запросы без утечки SQL

Specification как решение проблемы комбинаторного взрыва методов поиска. Specification как чистый предикат и как AST с интерпретаторами. Конструкторы (where, and, or, not), интерпретатор evaluate. Specification в контракте Repository. Доменные спецификации как именованные бизнес-правила. InMemory и SQL интерпретаторы. Сравнение Specification vs Filter Object. Specification для валидации.

TodoRepository: полный контракт для Todo-агрегата

Полный production-ready контракт TodoRepository. Доменные типы, ошибки (RepositoryError, ConcurrencyError, DuplicateTodoError), TodoFilter, TodoQueryOptions, TodoSortField. InMemory-адаптер с фильтрацией, сортировкой и пагинацией. Использование в Use Cases (CreateTodo, CompleteTodo, ListTodos). Контрактные тесты для каждого инварианта. Утилиты getTodoOrFail, updateTodo.

Упражнения: спроектируй Repository для TodoList

Практика: проектирование контракта ProjectRepository, реализация InMemory-адаптера, контрактные тесты, Generic Repository фабрика, Specification Pattern, проверка Dependency Rule, декоратор Repository с логированием.

Domain Events: уведомление о том, что произошло в домене 7 глав

Domain Event: факт, произошедший в прошлом

Что такое Domain Event, зачем нужны доменные события, отличие от системных событий и сообщений. Философия событийного мышления. Связь с Ubiquitous Language. Роль событий в DDD: коммуникация между агрегатами, аудит, Event Sourcing preview. Паттерн 'tell, don't ask' через события. Иммутабельность и временная метка. Примеры из Todo-домена.

Проектирование событий: имя, payload, метаданные

Правила именования доменных событий. Структура события: заголовок, payload, метаданные. Гранулярность событий — тонкие vs толстые. Envelope Pattern. Correlation и Causation ID. Версионирование. EventId и идемпотентность. Практические правила проектирования. Антипаттерны. Полные примеры из Todo-домена с Effect-ts.

Event как Schema.TaggedClass: типобезопасные события

Реализация Domain Events через Effect Schema.TaggedClass. Базовый класс DomainEvent. Discriminated Union из событий. Decode/Encode для сериализации. Schema.Union для паттерн-матчинга. Branded Types в событиях. Генерация Arbitrary для тестирования. Полный модуль событий Todo-домена с Effect-ts.

Агрегат → Event: события как результат поведения

Паттерн порождения событий из агрегата. Два подхода: State-first и Event-first. Функция apply: (State, Event) → State. Иммутабельное обновление агрегата через события. Возврат кортежа (State, Events). Накопление событий в агрегате. Связь с Event Sourcing. Подготовка к Части IX. Практические примеры с Todo-агрегатом.

Dispatching: PubSub через Effect

Механизм публикации и подписки на доменные события. EventBus как Driven Port. Effect PubSub для in-process dispatching. Синхронная vs асинхронная доставка. Гарантии доставки: at-most-once, at-least-once, exactly-once. Ordering и partitioning. Обработчики событий: EventHandler. Декларативная регистрация подписчиков. Ошибки обработчиков. Dead Letter Queue. Полная реализация EventBus для Todo-домена.

События Todo: Created, Completed, Archived, TitleChanged

Полная реализация всех доменных событий Todo-приложения. Каждое событие: мотивация, Schema.TaggedClass определение, фабричная функция, apply-handler, пример использования. Todo Aggregate с порождением событий. Модуль событий. Integration Events для межконтекстной коммуникации. Полный пример потока данных: HTTP → UseCase → Aggregate → Events → Handlers.

Упражнения: реализуй события для Todo-домена

Практические задания: создание новых типов событий, реализация apply-функций, паттерн-матчинг, round-trip тестирование через Schema, интеграция с EventBus, построение проекции (Read Model) из событий, реализация идемпотентного обработчика.

Типобезопасный домен: Гексагональная архитектура на базе Effect

Оглавление