Information
Specialization
Бэкенд разработчик, Архитектор программного обеспечения
Управление проектами
Планирование
Java
DDD
Микросервисная архитектура
PostgreSQL
Проектирование
Разработка программного обеспечения
Проектирование архитектуры приложений
Спасибо за детальный разбор!
По поводу зависимости на схеме, я рассмтривал зависимости в практическом смысле рабочей системы: ядру для выполнения его функций требуются конкретные реализации. Если смотреть на это с позиции классических принципов вроде инверсии зависимостей (DIP), то звучит всё с точностью до наоборот, здесь пожалуй стоит все же привести именно классический пример, поправлю
Что касается выбора самого ядра это не догма, а гипотеза, основанная на понимании предметной области. Да, её можно сформулировать неудачно, и тогда ядро придётся корректировать. Весь смысл подхода не в том, чтобы с первого раза найти идеальную абстракцию, а в том, чтобы сознательно искать наиболее стабильные точки опоры. Если ядро меняется часто — это сигнал к тому, чтобы пересмотреть анализ, а не идею.
Пример с канализацией в спальне крут) Но он показывает не провал подхода, а провал в его применении. Если например разобрать этот пример дальше, то ядро это не просто каркас из бетона, а система правил: где проходят магистральные стояки, где расположены технические шахты. Ошибка с трубой в неположенном месте это ошибка либо на этапе создания ядра (правила были плохими), либо на этапе проектирования модуля (дизайнер комнаты эти правила проигнорировал). Идея как раз в том, чтобы такие ошибки были локализованы и не вели к полной перестройке всего здания.
В целом я бы тоже обязательно спросил - "А за каким чертом вы мне сделали выход канализации в спальне?"