Module T

Чтобы упорядочить разработку дизайна рудиментов и получить пригодный на практике кусок вводится понятие Модуль T - общая реализация нескольких компонентов, которые вместе позволяют получить сложное сочетание логики и полезных свойств. В него входят компоненты, которые могут решить законченный логически скоуп задач на пересечении типовых обязанностей:

• доступ к ресурсу извне
  • CRUD как необходимый минимум
  • batch-операции (CreateAll, DeleteAll, ReplaceAll)
  • Query API, который можно выполнить и над коллекцией в памяти и над SQL/noSQL базой
  • recons-операции (дельта к предоставленному, стратегии реконсиляции)
• эффективное сохранение ресурса (persistence)
• бизнес-процесс поверх агрегата

Разное сочетание подключенных Port и Skill позволит реализовать типовые сценарии:

• CRUD + Batch как к ресурсам
• Recons когда нет возможности или потребности следить за последовательностями изменений, но надо понять разницу между состояниями (например, не запускать повторно сложные вычисления, если не меняется одно из полей)
• если отключены все порты, кроме бизнесового - получится Black Box с заданными разработчиком API. Как вариант, может оставаться только доступ на чтение.

Эффективность сохранение обеспечивается подходами:

1. WAL из Memory является append-only, он на фундаментальном уровне быстрее и надежнее изменения состояния агрегата в SQL/noSQL базе, имеет смысл на уровне Router требовать блокирующего сохранения Memory (мб за исключением effect)
2. Recons, даже если недоступен через порт, будет реализован, а значит изменения агрегатов можно делать настолько точечно, насколько потребуется. В отличие от простого CRUD, можно использовать разные стратегии в разных ситуациях
3. Проекция Memory модуля на уровне адаптера - это saga-pattern, возможно реализовать retry и rollback всего происходящего
4. устройство skill предполагает, что можно реализовать event store, т.е. распределить выполнение (например, по ID) между инстансами модуля, (не обязательно локальными!) и синхронизировать их между собой применением потока Event

Кроме основных функций есть вспомогательные:

• аудит, saga, module log и WAL - все через Memory
• pessimistic lock по ID[T] (вероятно, через акторы) чтобы по агрегату действия всегда выполнялись упорядоченно и с явным блокированием (Lock & Ordering)
• позже можно сделать ACL и RBAC вплоть до выделенных полей
• коммутация сообщений через Router и систему команд, чтобы сделать Memory и Lock простыми, но неизбежными

Вишенкой на торте будет система маппингов-Transit'ов, которые позволят поддерживать устройство агрегата и его команд в системе типов. Будет доступна после реализации Type System Module

Manageable Module T

В модуле все компоненты работают с сообщениям, связанными с типом T или с бизнес-логикой (которая опирается на T как агрегат).

Это значит, что если сделать Type System изменяемой извне и научив Module T опираться на изменяемый тип - чтобы модуль реинициализировал измененные части, перестроил транзиты - можно будет получить управляемый модуль на основе типа.