Please enable JavaScript.

Coggle requires JavaScript to display documents.

DDD. Паттерны, принципы Миллет, Часть 1. Принципы и приёмы DDD, Часть 3:…

- - - - Способна показать что она делает и зачем
    - - Способна отвечать на вопросы в предметной области
    - - Избегать абстракций из-за того, что они усложняют модель
      - Использовать их только для поведения, не стоит туда включать инфраструктурные вопросы
- - - - Simple Object Access Protocol
    - - Windows Communications Foundation
    - - Web Service Description Language
    - - URL - это разновидность URI
    - - GET - получить
      - DELETE - удалить
      - PUT - создать
      - POST - изменить
      - Типы содержимого
        
        application/hal+json
        
        HAL - hypertext application language
        
        application/atom+xml
        
        Atom - формат синдикации лент новостей. Отлично подходит для представления списков событий
      - Гипесреда
        
        Имеет точку входа в формате HAL
        
        Формат может быть JSON или XML
        
        Содержит ссылки на себя и другие сущности по ключу _links
        
        Есть ссылки
- - - - Создание модели
      - Общий язык
      - Разбивание сложных моделей на ограниченные контексты
      - Понимание отношений между контекстами
      - Дистиляция предметной области
        
        Это разделение бизнес-процессов на понятные части
    - - Описание
        
        Это строительные блоки моделей
        
        Набор шаблонов, помогающий создавать модели
      - Категории
        
        Управляющие сложностью задачи
        
        Управляющие сложностью решения
      - Шаблоны
        
        Концентрация на смысловом ядре
        
        Изучение через сотрудничество
        
        Создание моделей посредством исследований и экспериментов
        
        Коммуникация
        
        Понимание границ применимости модели
        
        Постоянное развитие модели
- - - - Состоит из трёх частей
        
        Имя класса, представляющее понятие предметной области
        
        Область ответственности
        
        Классы, которые связаны с данным класом и нужны ему
    - - GWT
        Given, When, Then
        Дано, Если, Тогда
        
        Дано - изначальные условия. Например, кто или что
        
        Если - одно или более возникающих событий
        
        Тогда - ожидаемые результаты
    - - Можно сделать интерфейсы и временный код, который проверит сделанную модель в действии
      - Обсуждать нужно только в рамках определённого контекста
  - - - Триггеры-команды
      - Участник\система
      - События
    - - Можно почитать книгу Гойко Аджича
    - - Книга построение бизнес-моделей
      - Столбцы таблицы
        
        Ключевые партнёры
        
        Ключевые виды деятельности
        
        Ключевые ресурсы
        
        Ценностные предложения
        
        И тд
    - - Исследование сценария с экспертом предметной области
      - Моделирование
        
        Событийным штурмом, например
      - Проверка модели
        
        Проверка модели на других сценариях, предложенных экспертом
      - Подведение итогов и документирование
      - Создание пробного кода
- - - - Стараться найти стороннее решение, не тратить сил
    - - Стараться найти стороннее решение, не тратить сил
- - - - Предметная модель - это упрощённая предметная область, решающая в коде бизнес-задачу
      - Аналитическая модель\Бизнес-модель - это набор артефактов, описывающих модель системы
      - Программная модель
        
        Должна максимально совпадать с аналитической моделью. Это обеспечивается единым языком
      - Программная модель служит основным представлением предметной области
  - - - Например, нельзя говорить на примере реализации: Клиент нажал на кнопку вернуть заказ...
    - - Это помогает удерживать в центре внимания процесс, а не реализацию. Работать в пространстве задачи, а не её решения
      - Взамен слов "нажать кнопку вернуть заказ" нужно формулировать так: "отправил уведомление о необходимости вернуть заказ"
      - Просить экспертов концентрироваться на что и почему, а как это сделать попросить положиться на разработчике
      - Эффективные приёмы формирования языка
        
        Нужно говорить экспертам про термины, которые они не заметили или исключать термины, которые не правильно поняли
        
        Составить словарь терминов
        
        Избегать терминов разработки
        
        Проверяйте модель, проговаривая её вслух
      - Как создавать эффективные предметные модели
        
        Жертвуйте точностью, если она стоит на пути к хорошей модели
        
        В модели не должно быть ничего лишнего
        
        Она проста и эффективна в том контексте, в котором была создана
        
        Включайте в модель только то, что имеет отношение к задаче
        
        Предметные модели лишь временны
        
        Избегать абстракций. Например взамен перемещения нужно называть конретно "прогулка пешком"
- - - - Использовать только когда бизнес-модель сложная
      - Сложен
    - - Полезен до того момента, пока отсутствует дублирование кода. Иначе нужно использовать предметную модель
      - Прост
    - - Удобен когда объектная модель и модель базы данных не имеют расхождений. Иначе нужно применять предметную модель
      - Каждому объекту соответствует своя таблица БД
    - - Является разновидностью модуля таблиц
      - Каждому объекту соответствует строчка таблицы
    - - Объекты только хранят данные
      - Нарушает принцип говори, а не спрашивай
- - - - Не имеют состояния
  - - - Службы должны экспортировать функции, а не изменяться под требованием клиентов
    - - Прикладные службы должны предоставлять эти отчёты не раскрывая детали реализации
    - - Транзакционная модель
        
        Чтобы предотвратить изменение предметной модели в угоду представлению, данные для представления можно хранить отдельно
      - Модель чтения
- - - - Деление на подобласти
  - - - Нужно постоянно созавать новые, экспериментировать
      - Не привязываться к старым
    - - Проектируйте модель так, чтобы самые частые изменения модели затрагивали меньшее число типов
  - - - Лучше отбрасывать те задачи, которые обойдутся без автоматизации
- - - - Могут иметь идентификаторы, но они не являются гарантией их уникальности
    - - Например, калькулятор стоимости доставки
      - Должна иметь имя в виде явного предметного понятия
      - Организуют выполнение предметной логики, но не реализуют её
    - - Упрощают представление больших предметных моделей
      - Имена берутся прямо из единого языка
  - - - Всегда должны находиться не в противоречивом состоянии (Не должны существовать инварианты)
    - - Фабричный метод
        
        Использовать для простых случаев
      - Фабрика
        
        Можно использовать для воссоздания из репозитория
      - Могут использоваться для сущностей или объектов-значений
      - Гарантирует соблюдение инвариантов после создания
    - - Лишь элемент для сохранения или извлечения данных
  - - - Сущность публикует события
      - Обработчики подписываются на них
      - Подробнее в главе 18
    - - Все события предметной области сохраняются вместо сохранения снимков
- - - - Каждое изменение должно порождать новый объект-значение
    - - Сущности можно складывать, отнимать и т.д.
    - - Вызываются исключения при противоречивом состоянии
      - Проверку можно делать несколько путями
        
        В фабричном методе
        
        Но тогда можно обойти проверку, просто вызвав конструктор
        
        В программном контракте (или наверное правиле)
    - - Неизменяемость позволяет не использовать моки или не тестировать побочные эффекты
      - Согласованность позволяет тестировать в полной изоляции
      - Комбинирование позволяет проверять взаимоотношения
  - - - FromFeet, FromMeters
    - - Увеличивает ясность кода
      - Исключает человеческие ошибки
      - Добавляет много ненужных уровней косвенности
    - - Например, список телефонов клиента можно заменить на PhoneBook
  - - - Сущность можно сохранять целиком в один объект
    - - Простая денормализация
        
        Определение формата хранения
        
        Можно определить метод toString и сохранять в БД это значение
      - Сохранение значений
        
        Можно определять в ORM свои типы для сохранения
        
        Нужно изучить встроенную в ORM поддержку объектов-значений
      - Парсинг значений при загрузке
        
        Для нестандартного отображения в БД можно определить свою точку входа во фреймворк
      - Нормализация в отдельные таблицы
        
        Для этого можно использовать mapper фреймворка
- - - - Сушности имеют уникальность
      - Сущности имеют жизненный цикл
      - Отвечает за "кто", "что", а не "какой"?
  - - - Естественные ключи
        
        Примеры
        
        Номен социального страхования
        
        Название страны
        
        Номер рассчётного счёта
        
        Национальный идентификационный номер
        
        Код ISBN (для книг)
      - Искуственные ключи
        
        Возрастающие последовательности чисел
        
        Требует глобальный счётчик
        
        GUID/UUID
        
        Может создаваться где и когда угодно
        
        Строки
        
        Идентификаторы, создаваемые базами данных
    - - Сущности нужно делать максимально компактными, перенося всё в объекты-значения
      - Желательно не делать слишком большой уровень вложенности
    - - Всё тоже самое, что и в объектах значениях, только ещё нужно проверять в методах, изменяющих состояние сущности
      - Проверка зависит от контекста, а инварианты должны соблюдаться всегда
    - - Изменение сущности должно происходить только внутри неё, с помощью методов
      - Нужно исключить сеттеры, давая имена предметным понятиям
    - - Моделировать только необходимые вещи
      - Исключать перетекания потребностей представления в модель
    - - Нужно всегда дробить модели на контексты вне зависимости от реапределённая система или нет
  - - - Параметры спецификации передаются в метод
      - Спецификации можно соединять
    - - Переход в следующее состояние делает бесполезными методы для предыдущих состояний
      - Нужно моделировать каждый статус в отдельном классе. Этот класс должен иметь метод для перехода в следующее состояние, создающее следующий класс
    - - Скрыть геттеры сущности можно путём создания отдельных классов-снимков(хранителей) этой сущности
- - - - Инкапсуляция бизнес-правил и процессов
      - Представление контрактов
        
        Реализация предметной службы может быть за пределами модели, а интерфейс будет определён в ней
        
        Примеры
        
        идентификация сущностей
        
        определение обменного курса
        
        определение суммы налогов
        
        рассылка извещений в реальном времени
    - - Служба не имеет состояния и реализует только поведение
      - Реализует предметную модель, которая не относится ни к какой сущности
  - - - Прикладная служба извлекает сущности из репозиториев и передаёт их предметной службе
    - - Например, предметная служба для рассылки уведомлений нужна в сущности после подтверждения бронирования.
      - Способы передачи службы в сущность
        
        Связывание вручную
        
        Например, создавать предметную службу в конструкторе сущности
        
        или вызывать псевдоконструктор init со службой в репозитории
        
        Использование механизма внедрения зависимостей
        
        IOC
        
        Локатор службы
        
        Вызывать в конструкторе ServiceLocator.Get<IServiceNotifier>
        
        Это вызывает жёсткое связывание с ServiceLocator
        
        Сложно мокать
        
        Неочевидно использование локатора со стороны клиента
        
        Применение двойной диспетчеризации
        
        Передача службы в метод сущности, а уже сущность передаёт себя в метод службы
        
        Недостатки
        
        Накладывает на вызывающий код ответственность, которую он не должен нести
        
        Зависимости не должны передаваться в метод. Сигнатуры методов не должны быть настолько изменчивы
        
        Ослабление связей с помощью предметных событий
        
        В сущности посылается предметное событий через диспетчер событий
        
        Подписчик подписывается на события определённого типа
        
        Диспетчер событий вызывает подписчика
        
        И в подписчике уже вызывается предметная служба
        
        Таким образом сущность не знает про службу
        
        Должны ли сущности знать о существовании предметных служб?
        
        Многие практики DDD считают это спорной идеей
- - - - Это простой класс со свойствами
    - - Обработчики событий нужно реализовывать так, чтобы они соблюдали границы транзакционности. Чтобы при выполнении одного обработчика, можно было откатить изменения предыдущих обработчиков.
    - - Внутренние события
        
        Происходят в пределах одного ограниченного контекста
        
        Могут содержать предметные объекты
        
        Не требуется поддерживать версионность
      - Внешние события
        
        Используются другими контекстами
        
        Не содержат предметных объектов, могут содержать только плоские данные вроде идентификаторов
      - Реализовывать в разных пространствах имён
  - - - Моделирование последовательностей, происходящих в предметной области
    - - Поддержка взаимодействия с другими ограниченными контексты
      - Такие обработчики не являются частью общего языка
      - Взаимодействуют со внешними службами, такие как системы платежей
  - - - Шина может поддерживать как синхронную, так и асинхронное выполнение
      - NServiceBus поддерживает оба
      - Этот подход привязывает к технологии в предметной области
    - - Регистрация обработчика DomainEvents.Register<DeliveryGuaranteeFailed>(onDeliveryFailure)
      - В обработчике в примере книги публикуется новое уже внешнее событие
      - Публикация события DomainEvents.Raise(new DeliveryGuaranteeFailed(this))
      - Решение проблем многопоточного выполнения
        
        Поставить [ThreadStatic] в коллекции обработчиков
      - Замена статического класса внедрением в методы
        
        Чтобы не использовать статические методы DomainEvents, можно пойти следующим путём
        
        Для этого обработчик событий можно передать в метод предметной модели
    - - Сущность собирает предметные события в своих методах
      - Прикладная служба передаёт события диспетчеру событий и диспетчеризирует их через dispatch
      - Чтобы не использовать коллекцию событий в сущности, можно передать событие напрямую в диспетчер в методе сущности. А диспетчер затем их выполняет на уровне службы как и раньше
        
        Но этот приём загрязняет сигнатуру методов
    - - Container.ResolveAll<IHandles<>
- - - - Это упрощает предметную логику
    - - Нужно ограничивать количество извлекаемых записей до такого количетсва, сколько нужно для соблюдения инварианта
    - - Нужно использовать ровно столько объектов, сколько необходимо для сценария
      - Вместо ссылок на объекты, лучше использовать их идентификаторы и репозитории для извлечения их в нужных сценариях при необходимости
  - - - Предметные инварианты - это инструкции или правила, которых всегда следует придерживаться
        
        Их нарушение влечёт неточности в моделировании предметной области
      - Когда все объекты, связанные с инвариантом находятся в пределах одного агрегата, их проще согласовать
    - - Границы согласованности
      - Строгая согласованность внутри
        
        Извлекаться и записываться в базу должны только агрегаты
      - Потенциальная согласованность снаружи
        
        Два агрегата не могут знать об одновременных изменениях друг-друга. Нужно учитывать, что они могут быть рассогласованы.
        
        Рассогласованность - это хорошо для масштабируемости и простоты системы, но плохо для некоторых бизнес-сценариев
      - Специальные случаи
    - - Нужно использовать как можно меньшие агрегаты
      - Большие агрегаты могут ухудшать производительность
      - Большие агрегаты более восприимчивее к конфликтам параллельного доступа
        
        Большое количество сценариев использования агрегата - симптом неправильно выбранных границ
      - Большие агрегаты могут плохо масштабироваться
  - - - Границы агрегатов нужно строить по инвариантам
      - Сущности, не задействованные ни в каких инвариантах по-умолчанию являются агрегатами
    - - Нужно стараться ограничить агрегат одним сценарием использования, чтобы он менялся в рамках только одной транзакции
      - Если несколько агрегатов меняеться в рамках одной транзакции, это признак не правильно выбранных границ агрегата
    - - Если для интерфейса нужно несколько агрегатов, тогда нужно сделать прикладную службу, которая извлекает несколько агрегатов и отображает их в интерфейсе
      - Есть ещё способы в главе 26 (с помощью посредника) и 25 (с помощью хранителя)
      - Если для интерфейса требуется загружать слишком много данных, тогда нужно применить CQRS
    - - Если кажется, что агрегат содержит коллекцию сущностей, то нужно убедиться, что эти сущности участвуют в инвариантах. Если не участвуют, то эти сущности не должны входить в агрегат.
    - - Нужно постоянно пересматривать структуру агрегатов
      - Новые сценарии помогают этому
      - Можно делать реорганизацию для повышения производительности
  - - - Корнем агрегата является сущность, которая является воротами в агрегат
    - - Корень агрегата экпортирует поведение всего агрената. Через его метод выразительно вызывается поведение агрегата
    - - Нужно скрывать внутреннюю структуру корня агрегата
      - Чтобы это сделать, нужно закрыть все методы и свойства, которые не относятся к поведению, от внешнего вызова
  - - - Вместо ссылок предпочтительней передавать копии объектов
    - - Только с помощью идентификаторов
  - - - В отчётах можно использовать предметные объекты отдельно
    - - Иначе это вызовет проблему n+1
  - - - Технологии для обмена сообщениями
        
        Kafka
        
        Akka
        
        NServiceBus
  - - - Пессимистическая
      - Оптимистическая
- - - - Цели шаблона фабрика
        
        Сокрытие сложностей создания
        
        Какому классу отдать предпочтение
        
        Как осуществлять поддержку инвариантов
        
        Ясное выражение вариантов создания экземпляров объектов
- - - - Многие разработчики ошибочно думают, что репозиторий мешает работать с данными
    - - Нельзя делать абстракции в интерфейсах шаблонов
  - - - Вначале нужно находить решение в предметной модели, только затем его адаптировать под технические детали
  - - - Способы слежения фреймворков за изменениями агрегатов
        
        Делает снимок при извлечении, а затем сравнивае его с изменённым агрегатом и решает что с ним делать после этого
        
        Возвращает прокси-объект агрената и следит за его изменениями
  - - - Версионность записываемых данных
      - Версионность отображаемых пользователю данных
  - - - Если нужно грузить только часть агрегата, то это значит не правильно определённые границы
  - - - Пример для NHibernate
        
        Настройка решения
        
        Infrastructure
        
        DomainEvents
        
        Класс поддержки предметных событий
        
        ValueObject
        
        Базовый класс объектов-значений
        
        Entity
        
        Базовый класс сущностей
        
        IClock
        
        Интерфейс для класса часов
        
        SystemClock - реализация интерфейса
        
        Model
        
        Auction
        
        Агрегат
        
        Содержит исключения в своём namespace
        
        Имеет единственный метод, позволяющий сделать ставку
        
        Money
        
        Объект-значение
        
        Инварианты
        
        Не больше нуля
        
        Дробно 0.01
        
        Offer
        
        Объект-значение для предложения
        
        Price
        
        Объект-значение цены
        
        WinningBid
        
        Объект-значение принятого предложения участника
        
        AutomaticBidder
        
        Предметная служба, делает ставку от имени участника, поовышая её, если его ставка была перебита
        
        BidPlace
        
        Предметное событие размещения ставки
        
        Outbid
        
        Предметное событие побития ставки
        
        IAuctionRepository
        
        Репозиторий аукциона
        
        BidHistory
        
        Bid
        
        Объект-значение идентификатора
        
        IBidHistoryRepository
        
        Репозиторий историй ставок
        
        Имеет два метода
        
        2 more items...
        
        Прикладные службы
        
        BusinesUseCases
        
        NewAuctionRequest
        
        DTO, Команда создания аукциона
        
        CreateAuction
        
        Прикладная служба создания аукциона
        
        Использует в своей работе
        
        2 more items...
        
        Возвращает идентификатор созданного аукциона в guiid
        
        BidOnAuction
        
        Команда предложения ставки на аукционе
        
        Обрабатываются предметные события
        
        2 more items...
        
        Обрабатываются исключения, если аукцион параллельно изменился для повторной попытки сделать ставку
        
        Queries
        
        Реализация репозитория NHibernate
        
        AuctionRepository
        
        Всё делегируется в ISession
        
        Модель аукциона и его истории маппится через xml-файл в данные
        
        BidHistoryRepository
        
        Помимо остального содержит SQL-запрос об общем количестве ставок
        
        Требования NHibernate
        
        Чтобы NHibernate работал, все конструкторы сущностей и объектов-значений должны быть без агрументов. Это реализуется путём добавления второго приватного конструктора без агрументов
        
        У каждого агрегата должно быть свойство Id и Version
        
        Справочные службы
        
        Сообщают информацию об аукционе, обходя предметные модели
        
        Queries
        
        AuctionStatus
        
        DTO, класс состояния аукциона
        
        ActionStatusQuery
        
        В конструкторе принимает
        
        3 more items...
        
        В методе ActionStatus напрямую вызывает ISession и через SQL извлекает нужные данные
        
        Репозиторий нужен для получения общего количества ставок по аукциону
        
        TimeRemaing возвращает оставшееся время аукциона с помощью IClock
        
        BidInformation
        
        DTO, класс с информацией о ставке
        
        BidHistoryQuery---
        
        Конфигурация
        
        Нужно настроить подключение к БД через XML
        
        Через Bootstrapper нужно объявить IoC зависимости с помощью StructureMap
        
        Представление
        
        Presentation
        
        Program
        
        Консольная команда со всем функционалом для демострации работы всех служб
        
        Способы отображения предметной модели в данные
        
        XML
        
        Атрибуты
        
        Сменный код
      - Пример для RavenDB
        
        Изменения модели
        
        Теперь не нужно свойства Id и Version
        
        Все свойства нужно сделать публичными
        
        BidHistory
        
        Новый объект для списка ставок на аукционе
        
        В репозитории ставок добавляется новый метод для поиска BidHistory
        
        Прикладные службы
        
        IDocumentSession вместо ISession
        
        Не нужно начинать транзакцию, но нужно делать SaveChanges
        
        Другое исключение в случае нарушения версии
        
        Справочные службы
        
        AuctionStatusQuery теперь иначе извлекает данные напрямую из сущности Auction, поскольку она имеет публичные свойства
        
        BidHistoryQuery теперь использует объект BidHistory, чтобы гарантировать порядок ставок. Порядок ставок - это предметная логика
        
        Хранить все данные в JSON
        
        Реализация репозиториев
        
        Нужно сделать класс индекса для ускореня поиска и подключить его использование в репозитории при получении сводной информации о ставках
        
        Сами репозитории переписываются под немного иной функционал
        
        Конфигурация
        
        Обозначить новые зависимости для IoC через Bootstrapper
        
        Указать настройки БД
    - - Пример для Entity Framework
        
        Изменение модели
        
        WinningBidSnapshot
        
        Класс для снимка победной ставки
        
        AuctionSnapshot
        
        Снимок аукциона (Внутри него есть свойство с WinningBidSnapshot)
        
        MoneySnapshot
        
        Money
        
        Добавить метод для создания снимка
        
        WinningBid, Auction
        
        Метод для создания снимка
        
        Метод-фабрика для создания объекта из своего снимка
        
        Реализация репозитория
        
        DataModel
        
        Нужно сделать DTO
        
        AuctionDTO
        
        BidDTO
        
        Mapping
        
        Нужно сделать класс для отображение DTO в таблицу БД
        
        BidMap
        
        AuctionMap
        
        AuctionDatabaseContext
        
        Тут настраиваются мапперы и DTO
        
        Является реализацией шаблона "Единица работы"
        
        AuctionRepository, BidHistoryRepository
        
        Работает с AuctionDatabaseContext
        
        Add
        
        Преобразовывает снимок агрегата в DTO и скармливает в DatabaseContext
        
        Save
        
        Находит свежий DTO и обновляет его данными из снимка агрегата
        
        FindBy
        
        Находит в БД DTO и преобразовывает его в снимок агрегата, из которого затем создаётся сам агрегат через метод-фабрику
        
        Прикладные службы
        
        Save явно заворачивается в транзакцию, поэтому не нужно всё оборачивать в транзакцию
        
        Другие классы исключений для параллельного доступа
        
        Справочные службы
        
        Из сущностей извлекаются снимки и конвертируются в DTO
        
        Настройка решения
        
        Конфигурация
        
        Задать связи для IoC
        
        Указать настройки БД через XML
      - Пример для Micro ORM
        
        Инфраструктура
        
        Нужно создать интерфейсы
        
        IAggregateDataModel
        
        Интерфейс-маркер
        
        Действует как метаданные для класса для идентификации объектов как сущностей, которые участвуют в транзакции
        
        IUnitOfWorkRepository
        
        IUnitOfWork
        
        Объявить класс для исключений параллельного доступа
        
        Мини-фреймворк с минимумом автоматизации
        
        Прикладные службы
        
        IUnitOfWork используется для того, чтобы закоммитить изменения
        
        Другое исключение для параллельного доступа
        
        Реализация репозитория на основе ADO.NET
        
        DataModel
        
        Нужно добавить во все DTO интерфейс IAggregateDataModel
        
        Репозитории реализуют интерфейсs I*Repository, IUnitOfWorkRepository
        
        Внутри вызывают IUnitOfWork для регистрации изменений
        
        А для чтения и записи создают напрямую подключение к БД
        
        Реализовать UnitOfWork
        
        Конфигурация
        
        Зависимости IoC
        
        Конфиг XML
- - - - Можно перемотать во времени любые изменения агрегата
    - - Это срез событий по критерию
    - - Используются для ускорения воспроизведения текущего состояния
  - - - Добавление поддержки регистрации событий
        
        Базовый класс агрегатов EventSourcedAggregate
        
        Хранит список событий
        
        Имеет метод apply для применения события
      - Поддержка событий в агрегате имеет особенности
        
        Способность агрегата применять предметные события
        
        Фиксируется список принятых событий, чтобы записать в хранилище
        
        Поддержка записи своих версий для возможности предоставлять моментальные снимки и предоставлять возможность восстанавливаться из них
      - Экспортирование выразительного предметно-ориентированного API
      - Добавление поддержки моментальных снимков
        
        Перегруженный конструктор может принимать снимок и настраивать агрегат. Он ещё проставляет версию
        
        Геттер Get...Snapshot возвращает снимок
    - - Создание репозитория с поддержкой регистрации событий
        
        Репозитории должны поддерживать три операции
        
        Создание потоков событий
        
        Извлекаются все события из свойства агрегата Changes
        
        И фиксируются в БД
        
        Добавление в конец потоков
        
        Загрузка потоков
      - Добавление поддержки снимков в операции сохранения и восстановления
        
        Фоновый процесс периодически создаёт снимки агрегатов
        
        Со снимками можно доработать метод репозитория FindBy и добавить туда извлечение последнего снимка агрегата. И извлекать только последующие события
      - Решение проблем параллельного доступа
        
        После извлечения агрегат должен сохранять первоначальный номер версии
        
        Перед сохранением необходимо сравнивать версию в хранилище и версию в агрегате
    - - Вначале прогоняется бизнес сценарий
      - Затем проверяется список незафиксированных событий в агрегате
  - - - Объекты
        
        EventStream
        
        Поток событий
        
        Умеет регистрировать событие и возворащать по нему EventWrapper
        
        Имеет версию в свойстве Version
        
        EventWrapper
        
        Добавляет к событию все метаданные
        
        SnapshotWrapper
    - - EventStore
        
        Создаёт документ для EventStream в БД RavenDB в формате JSON
        
        И добавляет в него одновременно массив событий
        
        Реализация хранилища для потоков событий
    - - EventStore
        
        AppendEventsToStore
        
        Записывает события EventWrapper в поток
    - - EventStore.GetStream
        
        Возвращает EventWrapper[] между fromVersion и toVersion
    - - EventStore.AddSnapshot<T>(string streamName, T Snapshot)
        
        Snapshot оборачивается в SnapshotWrapper и сохраняется в БД
        
        SnapshotWrapper предоставляет дату создания и название потока
      - EventStore.GetLatestSnapshot<T>(string streamName)
    - - EventStore.AppendEventsToStore(... int? expectedVersion = null)
        
        Сравнивает expectedVersion с версией извлечённого потока и выдаёт исключение, если они расходятся
      - Чтобы исключить состояние "гонки", нужно включить в RavenDB флаг оптимистичной блокировки
        
        Тогда попытки записать в один поток из разных сессий будут выдавать исключение
  - - - Есть универсальная схема с тремя таблицами:
        
        Events
        
        EventSources
        
        Snapshots
  - - - GetEventStore
        
        Реализация IEventStore с хранилищем Event Store
        
        CreateNewStream - создаёт поток событий и записывает указанный массив событий
        
        AppendEventsToStream
        
        GetStream
        
        AddSnapshot
        
        Снимки пишутся в отдельный поток событий для каждого агрегата
        
        GetLatestSnapshot
        
        Event Store поддерживает оптимистичную блокировку из коробки
        
        Это возникает из-за того, что он использует настоящие потоки
        
        EventStore.Client - это официальная клиентская библиотека к Event Store. Взаимодействует по протоколу TCP
    - - Запросы в Event Store формируются на JavaScript
        
        Вначале определяется какие события нужно запросить
        
        fromStream('PayAsYouGoAccount-54a..')
        
        Затем все найденные события передаются в when
        
        Возвращает объект JavaScript с нужными параметрами
        
        $init - стартовое состояние
        
        И параметры, которые нужно рассчитать
    - - Можно реализовать за счёт fromCategory(...).when(...)
    - - fromCategory(...).when({'CreditAdded': function (s, event) {linkTo('NewStreamId', event)}})
        
        Копирует события CreditAdded в новый поток NewStreamId
  - - - Проекции позволяют сделать материализированное представление
    - - Потоки событий в виде очередей
        
        Ленты Atom с событиями избавляют от необходимости использовать очередь и шину сообщений
      - Двухфазное подтверждение
        
        С регистрацией событий отпадает необходимость в распределённых транзакциях и их подтверждении.
  - - - Предоставляет возможности анализа всей хронологии событий
    - - Методы вроде when{Предметное событие}{Применить бизнес-правило} выразительны
    - - За счёт инкапсуляции хранилища, можно хранить где угодно
  - - - При изменении событий, нужно поддерживать или конвертировать все предыдущие версии событий
- - - - Автономность
        
        Контекст автономного приложения содержит в себе все данные, необходимые для его отображения
        
        Он берёт информацию из других контекстов с помощью подписки на их события
        
        Такие приложения имеют потенциальную непротиворечивость
      - Авторитетность
        
        Веб-страница сама запрашивает данные напрямую из их контекстов (авторитетных источников)
        
        В интерфейса самые свежие данные
      - Некоторые рекомендации
        
        Авторитетность или автономность нужно выбирать исходя из реальности, самый простой выриант
    - - HTML API - каждый контекст формирует свою часть интерфейса
        
        Недостаток - дробит задачи представления
        
        Плюс - даёт больший контроль ограниченным контекстам
      - Data API - каждый контекст предоставляет данные в JSON и интерфейс их собирает на своей стороне
        
        Это наиболее популярный вариант
        
        Минус - не даёт возможность контроллировать ограниченным контекстам своё отображение
        
        Плюс - изолирует задачи представления единым приложением
    - - Клиент
        
        Ослабляет зависимость от сервера
        
        Более отказоустойчиво
        
        Снижает сложность серверной стороны
      - Сервер
        
        Менее отказоустойчиво
        
        Быстрее работает в браузере
        
        Избавляет от необходимости в JavaScript
- - - - Обработчик команд - это разновидность прикладных служб
  - - - Нужно использовать легковесные ORM для того, чтобы быстро отображать данные в DTO модели представления
      - Нужно делегировать принятие решений на основе данных предметным службам и спецификациям
  - - - Шаблон можно реализовать без потенциальной противоречивости
      - Потенциальную непротиворечивость нужно внедрять только после проблем с производительностью
    - - Это нужно только когда требуется масштабирование
    - - Использование системы обмена сообщениями является плохой идеей, поскольку вносит лишние сложности
    - - Состояние агрегатов можно получать с помощью шаблона "хранитель"
      - Это не обязательное условие
  - - - Непротиворечивость
      - Доступность
      - Разделение
    - - Потенциально непротиворечивая модель чтения
        
        Модель представления берёт событие в очереди и обновляет свои данные
        
        Предметная модель записывает события в очередь
    - - Всегда показывать версию данных, которые видит пользователь
    - - Может работать для целей составного пользовательского интерфейса
  - - - Прикладная служба проверяет допустимость запроса
      - Запрос добавляется в очередь
      - Прикладная служба берёт запрос из очереди
      - И обрабатывает его
    - - Все неправильные значения команды, не зависящие от бизнеса, сразу проверяются перед добавлением в очередь
    - - Нужно предупреждать пользователя, что нужно немного подождать
- - - - Команда
      - Процессор команд
      - Цепочки команд
        
        Если сделать обобщённые команды и цепочки, то можно реализовать цепочки команд
        
        Каждый процессор является декоратором для указанного в конструкторе процессора
        
        Можно использовать для логгирования, перехвата исключений, фиксации транзакций
    - - Прикладная служба подписывается на предметные события
    - - Шаблон следует приципу одна модель на входе - одна на выходе (OMIOMO)
  - - - Нужно максимально избегать заглушек
- - - - Низкая производительность
      - Бытрое написание кода
      - Раскрываются объекты
      - Открываются свойства объекта
        
        Чтобы этого не было нужно использовать посредника
  - - - Поскольку возникает необходимость в подсчётах как в предметной модели
- - - - Обмен сообщениями
        
        Потенциальная непротиворечивость
        Eventual consistency
        
        Аббревиатура BASE
        Basically Available, Soft state, Eventual consistency
        Преимущественно доступный, с изменчивым состоянием, непротиворечивый
      - REST
      - Обмен файлами
      - RPC
      - Общая база данных
  - - - Не должны иметь зависимости от других компонентов
      - Это логические контейнеры
      - Не должны иметь общую БД
  - - - Использует данные унаследованной системы
    - - Имеет собственное хранилище данных
      - Синхронизируется асинхронно с унаследованной системой
    - - Служба экспортирует API в простом виде, которое позволяет внешним контекстам производить минимальные преобразования
      - Имеет недостатки, что нужно вносить изменения в старый код и вырабатывать новый API
  - - - Реактивная система более быстрая
      - Надёжность
- - - - Каждый компонент содержит в себе агента шины сообщений и может с помощью него работать с сообщениями и шиной
    - - Apache Kafka
      - Менее надёжнее шины
    - - Чтобы подтвердить доставку используются методики
        
        Доставка не менее одного раза
        
        Доставка не более одного раза
        
        Доставка точно один раз
    - - Если сообщение было получено получателем и подтверждено, оно удаляется, иначе отправляется повторно
    - - Команды образуют тесную связь между отправителем и получаетелем
      - События лишены этого недостатка за счёт паттерна издатель\подписчик
      - Команды должны именоваться как приказы
      - События должны называться согласно тому, что произошло в прошедшем времени
  - - - Шлюзы сообщений - это цепочка событий и их обработчиков для повышения отказоустойчивости между ними за счёт переобработки события в случае его отказа
  - - - Обращаться из доставки в другой контекст через RPC - это вызовет временную зависимость
      - Передавать адрес в сообщении. Это вызовет разрастание свойств сообщений по цепочке и усложнит отладку
      - Хранить данные локально
    - - Все нужные контексту данные сохраняются из внешних событий локально
    - - Данные концептуально различны
        
        Например, цена товара в доставке может отличаться от цены в каталоге
      - Избегайте несогласованности, используя сроки действия
      - Экономика дублирования данных
      - Нарушения порядка доставки сообщений
        
        Если сообщение о доставки пришло раньше, чем сообщение о регистрации с адресом клиента, тогда лучше отправить сообщение обратно в очередь
  - - - Мониторинг ошибок
        
        Большинство фремйворков помещают опасные сообщения в очередь error
        
        Сообщения, которые не удалось обработать даже после нескольких попыток, называют опасными
        
        Нужно мониторить очередь error программами
      - Мониторинг соглашений об уровне облсуживания
- - - - Так-же известно как dogfooding
  - - - SOAP
        
        Simple Object Access Protocol
        
        Со стороны сервера формируется интерфейс службы и передаётся в WCF
        
        Со стороны клиента по url качается WSDL и по ней генерируется прокси-класс
      - XML
        
        eXtensible Markup Language
      - JSON
      - Недостатки SOAP
        
        Излишняя сложность
        
        Слишном подробный формат сообщений, в результате они занимают много трафика
      - WCF
        
        Windows Communications Foundation
      - WSDL
        
        Web Service Description Language
    - - Этот вариант предпочтительней из-за более простых сообщений JSON
  - - - Ресурсы
      - Гиперсреда
        
        Все шаги бизнес-процесса можно обозначать в виде URI
      - Отсутствие информации о состоянии
        
        Лучше исключить запись состояния на стороне сервера
        
        Это уменьшает количество запросов к серверу
    - - Методы
      - Коды ответа
      - Заголовки
      - Чем не является REST
        
        Модель зрелости Ричардсона
        
        Показывает насколько ваш API близок к RESTful
    - - Прикладные интерфейсы для гиперсреды
      - Тестирование HAL API с помощью браузера HAL
      - Сохранение событий с помощью Event Store
        
        Это БД для событий