Хм, а в чем проблема с описанием взаимодействия на ООП? И чем ленивость или зависимые типы помогут для поведения?

Попробуй смоделировать игру в футбол :) Зависимые типы нужны для корректности, вроде ограничений "ф-я принимающая список из 1 и более элементов", например

А что это даст? Вот как это поможет для описания правила оффсайда, например?

Возможность компилятору доказать корректность

Это очевидно, как это поможет с описанием бизнес-правил?

Конфигурация бизнес-процесса тоже является частью модели. За маппинг конфигурации бизнес-процесса на конфигурацию приложения отвечает слой инфраструктуры.

Конфигурация - это про разное поведение и вот эту часть сложно внутрь модели упаковать

Пока не понятно. Можно пример?

Просто бизнес-правил - никак. Корректных бизнес-правил - очевидно как :)

А можешь пример показать. Ну вот про то же правило оффсайда.

Не совсем. Там есть "Critical Business Rules" (это как раз поведение Entities), и "Application-specific Business Rules" (это уже поведение UseCases). Если дословно, то:

A Use Case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A Use Case describes application-specific business rules as opposed to the Critical Business Rules within the Entities.
- “Clean Architecture: A Craftsman’s Guide to Software Structure and Design” by Robert C. Martin, Chapter 20 “Business Rules”

При этом у него имеется небольшое противоречие. С одной стороны, он пишет, что
"Business rules are the reason a software system exists.",
а с другой стороны - "Not all business rules are as pure as Entities. Some business rules make or save money for the business by defining and constraining the way that an automated system operates. These rules would not be used in a manual environment, because they make sense only as part of an automated system."

Не совсем понятно - “Business Rules” являются причиной существования Приложения, или имеют имеют смысл только как часть Приложения?

По этой причине лично я предпочитаю придерживаться формулировки Craig Larman и Eric Evans, где "Application Layer does not contain business rules", а термин Business является синонимом термину Domain.

Возможно, то, что статью https://martinfowler.com/bliki/AnemicDomainModel.html M.Fowler написал по итогу обсуждения этой темы с Eric Evans (о чем он говорит в первом абзаце).

Ну, что Фаулер не любит AnemicModel - не секрет )

если идти по rich model получаются казусы, вроде коробки которая сама запрыгивает на полку

ведь логика внутри

Если не пытаться в рамках доменной модели описать "реальный мир", то никаких казусов не будет.

зря, именно его и надо описывать

Хм, чтобы что?)

чтобы делать не космические театры бороздящие ...

И Хориков не ответил? По-моему, он знает по этой теме все. Он больше остальных авторов по DDD написал статей по этой теме:
- https://enterprisecraftsmanship.com/
- https://khorikov.org/
Я не нашел у него ни одного пробела по этой теме, хотя общался с ним на эту тему достаточно много. Если будете делать Панельную дискуссию, то есть смысл пригласить и его ( @vkhorikov ).