Ястолкнулся с такой проблемой: логика между доменами сложнее самих доменов
Если строить систему по DDD:
• Домены
• Агрегаты
• Use cases
• События
всё красиво.
Потом пришёл сценарий: «Отменить заказ»
Я думал: `Order::cancel()`, вызову `inventory.release()`, `pricing.refund()`, и готово»
Но...
• Если доставка уже в пути - нужно создать возвратную накладную
• Если платёж падал дважды - отменить всё, а при первой попытке только заморозить баллы
• Если товара нет - перенести резерв на другой склад, пересчитать доставку, спросить клиента, если дороже
• Если клиент повторил платёж - восстановить резерв и доставку
И я понял:
Самая сложная логика тут не в доменах, а между ними.
А в книжках по DDD, Clean Architecture, Hexagonal об этом не пишут.
Это напомнило проблему в ООП, когда каждый объект отвечает только за свою корректность (инвариант), а логическую зависимость при взаимодействии должен обеспечить ещё один класс "чистая выдумка". Также, у ФП есть более простые и явные способы.
Я напишу на Rust, потому что этот язык удобнее управляет бизнес правилами.
Читать далее