В продолжение формализации DDD, моя любимая темка "есть ТЗ на тысячи сущностей, условный dwarf fortress, ну и?". Я разбирал её в клубе в том году, сериал "Серебряная пуля в проектировании" применительно к ООП, но в основном с методологической точки зрения: как пошагово применять подходящие паттерны к задачкам подобного масштаба.

Сложность домена -- это константа. Вопрос, где она живёт :)

1000 сущностей, и все достаточно тесно связаны по большому счёту -- это SOL-сложность (и неразрешимость).

Мы же хотим декомпозировать домен до bounded contexts (размерами не более 50 сущностей), связи между которыми будут только на их границах, а главное, что каждый контекст - это FOL.

У нас есть класс Dwarf, который может двигаться и стрелять -- соответствующие методы, но на вопрос, а "когда это можно делать?" они никак не отвечают. А вот если мы декомпозируем по capability, то получаем нечто вроде

MovableFn = Callable[[], Tuple[MoveResult, Optional[MovableFn]]]

Этот тип сам говорит: "после вызова может не быть возможности двигаться". И глобальная корректность следует из композиции локально корректных элементов.

Собственно и математики примерно так же рассуждают, просто не знают об этом, если не программисты :) Для них bounded contexts -- это арифметика, топология, алгебра, каждый с конечным набором аксиом. А интерпретации между теориями -- это anti-corruption layers.

То есть, нам не нужна единая система из 1000 типов (как глобальная теория ZFC). Нам нужен протокол связи между контекстами, каждый из которых локально проверяем. Сама же теория нам нужна только для доказательства корректности протоколов трансляции между контекстами. Это я и имею в виду под формализацией DDD.

И остался ещё один нюанс конкретно про декомпозицию - как её правильно готовить?