начали появляться доклады jpoint 2025 🐝

сейчас в свободное время читаю книгу «Предметно-ориентированное проектирование» от Эрика Эванса (DDD). подумала, что здорово внедрить формат обзора в моменте.

итак, первая часть.

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

когда сложность модели выходит из-под контроля, разработчики перестают понимать свое изделие. качественно спроектированная архитектура позволяет грамотно использовать сложность системы.

выбор модели определяется тремя способами её использования:

1. модель и архитектура программы взаимно определяют друг друга
2. модель лежит в основе языка всей группы разработки
3. модель – это дистиллированное знание

моделирование не нацелено на создание максимально реалистичной модели. оно сродни съемке фильма – примерное изображение реальности, служащее конкретной цели.

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

в проекте без общего языка программисты становятся переводчиками. перевод затуманивает концепции модели. разные члены группы употребляют термины в разном смысле, и программа становится ненадежной.

диаграммы – средства коммуникации. они полезны, когда содержат минимум элементов. документация должна отражать смысл и прояснять крупные структуры, дополняя код и устную дискуссию.

единый язык должен появляться в дискуссиях и в коде. если этого нет, документация не выполняет свою задачу.

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

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

если сотрудники, пишущие код, не чувствуют ответственности за модель, то модель не имеет отношения к программе. если моделировщик отдален от реализации, он теряет интуитивное понимание требований. в итоге модель теряет практическую ценность.

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

💎 - спасибо за обзор! очень интересно

⚒сегодня смотрела видео n8n: оказалось занятной вещью.
ссылка на обзор

это open source платформа для no-code и low-code автоматизации, что-то вроде более гибкого и самодостаточного аналога zapier или make. она позволяет собирать бизнес-процессы и интеграции из визуальных блоков, запускать их по событиям, вебхукам, расписанию или ручному триггеру. при этом n8n не ограничивается только «перетаскиванием кубиков», а дает возможность писать свои кусочки логики прямо внутри нод, что делает ее удобной для разработчиков.

в ней можно:

• подключать внешние сервисы
• забирать и преобразовывать данные
• делать сложные цепочки действий
• разворачивать её у себя и полностью контролировать окружение
• расширять функциональность собственными нодами

по сути, это конструктор автоматизаций, который живет у вас, а не в чьем-то облаке.
например, кто-то с помощью нее наводит порядок в почте.

если кто-то использует, то поделитесь, для чего используете ⚙️

поговорим о неочевидных плюсах больших задач на основе моего опыта переноса сервисов с одной базы на другую.

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

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

растет зона ответственности. в какой-то момент ты перестаешь мыслить проектом, а начинаешь думать целым контуром.

большие задачи учат планировать по-взрослому. ты начинаешь закладывать риски, запас по времени, планы «Б». и вопрос уже звучит иначе: не сколько это займет, а что случится, если что-то пойдет не так. можем ли мы откатиться, сохранить систему и не нарушить ее жизнь снаружи.

большие задачи неизбежно показывают предел твоего текущего понимания. ты буквально “встречаешься с потолком”, понимаешь, где твои пробелы, и это болезненно, но крайне полезно.

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

и, наверное, самое ценное - учишься делегировать. на каком-то этапе понимаешь, что соль больших задач не в героическом «я сама», а в передаче контекста. в том, чтобы не только делать, но и объяснять, доверять, периодически возвращаться и смотреть, как это живет без тебя. и однажды ты ловишь себя на мысли, что это важнее скорости написания твоего собственного кода. это уже про антихрупкость команды и взрослое отношение к задаче

❤️ - спасибо за пост!

🥇словили очень приятное чувство с товарищем по работе
получили ту самую заветную 200

немного контекста: я делаю задачу, часть которой требует расширять keycloak и лезть глубоко в его внутренности. штука сама по себе непростая: отладка не выстроена, интеграции цепляют несколько сервисов, работа с сертификатами и т.д.

в начале недели у меня вообще не было времени на реализацию, поэтому временно подхватил коллега. в итоге получилось парное программирование.

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

в итоге вышло совместное решение.
и особенно приятно это ощущать на фоне того, что задача горит, многое завязано на другие команды, в спину дышит фриз.

радуюсь!
позднее расскажу, что это за фича такая была большая…

🟦недавно дочитала «Мама, я тимлид» Марины Перескоковой - очень понятный, практичный труд. автор делится реальными советами по руководству IT-командой на основе своего опыта.

пока читала, постоянно вспоминала разные ситуации из своей жизни, анализировала поведение руководителей и коллег, размышляла о том, что работало, а что нет, и какие выводы можно сделать для себя.

закину несколько цитат, которые особенно зацепили:

• «От специалиста ждут экспертных знаний в своей области, высокого качества работы, соблюдения сроков. От руководителя ждут, чтобы команда умела выполнять поставленные задачи, качественно делала свою работу и соблюдала сроки. … На вас лежит бремя за суммарный результат труда»
• «Многие ваши решения покажут свою правильность в перспективе года»
• «В современном мире перфекционизм оправдан только в некоторых специфических областях, большую часть бизнес-задач можно и нужно выполнять «достаточно хорошо» и не стремиться к идеалу»
• «Все по-настоящему классные руководители играют роль защитной стены между своей командой и внешним миром»
• «Человек не может организовать команду, если не может организовать себя»
• «Какая бы звезда не попала бы к вам в команду, сто раз подумайте, прежде чем прощать человеку скверный характер»
• «Важный момент в удаленной работе — это способность человека сохранять мотивацию к труду, когда на него никто не смотрит»

рекомендую каждому заинтересованному!

с Рождеством! послушала на одном дыхании очень интересный подкаст от Евгения Сулейманова и Михаила Поливахи

про что он:
⚙️ зачем разработчику контрибьютить в open source
⚙️ зачем разработчику быть спикером
⚙️ как это влияет на рост, видимость, уверенность и качество мышления
⚙️ как выбирать технологии и выстраивать обучение, если не хочется бегать за каждым трендом
⚙️ AI на рынке

посмотреть можно на youtube

📚обзор на ч. 2 «Предметно-ориентированное проектирование» от Эрика Эванса (Структурные элементы)

ч.1

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

на этом фоне smart ui выглядит как антипаттерн. вся логика живет в экранах, каждый контроллер сам ходит в базу, валидирует, считает правила, дергает интеграции. код отражает кнопки и формы, а не бизнес. язык предметной области не формируется, изменения становятся дорогими, усложнение ломает систему. при этом smart ui честно хорош для простых задач, админок, коротких проектов и быстрого старта. он просто несовместим с целью ddd - строить модель как носитель знания.

ассоциации стоит ужимать: каждая связь должна быть оправдана поведением, иметь понятную реализацию и не плодить лишнюю связанность.

сущность определяется не набором атрибутов, а непрерывностью существования и идентичностью во времени. она может менять форму, состояние, представление, но оставаться собой. у нее всегда есть идентификатор и четкое определение равенства. объект-значение наоборот существует как описание. важны не «кто», а «какое». адрес, деньги, период, координаты. value object желательно делать неизменяемым, чтобы безопасно передавать и переиспользовать. если изменяемость нужна ради производительности, ее надо изолировать и не делить между владельцами.

не все процессы естественно ложатся в объекты. если операция не является органической частью ни сущности, ни value object, появляется служба. служба не хранит собственного состояния, описывается через язык модели и выполняет конкретную доменную операцию. это не технический сервис, а элемент предметной модели. при этом службами нельзя злоупотреблять, иначе модель теряет поведение.

модули в ddd - это не просто пакеты. это главы истории модели. они должны отражать смысловые границы, помогать мышлению, снижать связанность и повышать связность внутри. имя модуля должно входить в единый язык. если модуль сложно описать словами предметной области, значит граница выбрана плохо.

агрегат задает границы согласованности. это группа связанных объектов, которая изменяется как единое целое. у агрегата есть корень, и только он доступен извне. внешние ссылки могут указывать только на root. внутренние сущности живут только внутри агрегата. агрегат определяет транзакционные границы, изоляцию и правила доступа.

создание сложных объектов и агрегатов выносится в фабрики. фабрика скрывает детали сборки, гарантирует инварианты и возвращает корректный объект сразу в рабочем состоянии. фабрика - архитектурный элемент, а не бизнес-сущность. иногда она живет в корне агрегата, иногда в отдельном объекте, иногда внутри логического владельца. простой объект можно создавать через конструктор, но порог для фабрики в ddd довольно низкий.

хранилище инкапсулирует доступ к устойчиво существующим агрегатам. клиент работает с иллюзией коллекции в памяти: добавляет, удаляет, ищет по критериям. хранилище скрывает технологии хранения, упрощает тестирование и изолирует инфраструктуру от модели. важно, что хранилище не управляет транзакциями. фабрика создает новые объекты, хранилище извлекает существующие, даже если технически тоже конструирует экземпляры.

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

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

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 1: контекст и работа с кодовой базой]

весной 2025 я начала работать над задачей перевода проекта с Oracle на PostgreSQL.

с чем имеем дело:
1. микросервисная архитектура
2. java, spring boot. в коде и нативные sql-запросы, и hibernate
3. активные бизнес-релизы, команда постоянно выкатывает новые фичи
4. человеко-ресурсы ограничены: я, позже 1-2 разработчика (в зависимости от фазы), 1 devops и 1-2 qa
5. ключевое - никакого даунтайма. пользователь не должен заметить, что под капотом вообще что-то меняется

при таких вводных перевод проекта с одной базы на другую - это не «миграция», а отдельный длительный процесс, который живет параллельно с развитием продукта.

если обобщать, процесс состоит из нескольких крупных этапов:
1. анализ и очистка данных
детальный разбор накопившегося легаси, неиспользуемых таблиц, исторических костылей
2. миграция данных
3. переработка liquibase
4. переработка прикладного кода микросервисов
учет нативных запросов, особенностей ORM, тех самых «так исторически сложилось» и т.д.
5. организационные и процессные вопросы
подготовка инфраструктуры, коммуникация с командами, синхронизация бизнес- и тех-релизов, стратегия веток, взаимодействие с сопровождением и dba, заранее продуманные сценарии проблем и способы их решения. техническая часть - это лишь половина задачи. вторая половина - люди, процессы, ограничения и договоренности.

к чему стремилась: в PostgreSQL есть все исторические данные, поды пишут в нее новые напрямую — и это все без даунтайма.

в этой части я расскажу о работе на уровне кода.

при продумывании перехода важно сразу учитывать различия между базами.
например, в Oracle пустая строка фактически равна null, в Postgresql такого поведения нет. или, например, boolean в виде 0/1 или Y/N становится честным true/false.
мы очень много правили кастомные запросы и clob. было много разных ситуаций.

liquibase правили по принципу: пока не запустится - чиним.
во многих местах хватало массовых правок через ide (например, number(1,0) -> boolean). важно не забывать и про dbms-фильтры в liquibase (например, dbms=oracle), которые легко пропустить.

для запуска скриптов использовали контексты:
• ddl - context="!PREP and !PROD"
• dml - context="!IFT and !PREP and !PROD"

ddl в первом случае накатывался отдельным процессом (через ДБА), а dml фактически не требовался - но к этому я еще вернусь позже.

еще один исторический нюанс - использование sequence в некоторых сервисах. при миграции данных пришлось отдельно продумывать механизм динамического сдвига значений, чтобы избежать коллизий после переключения. мы реализовали это на старте pod-а: проходились по всем sequence микросервиса, сравнивали значения в oracle и postgresql и при необходимости сдвигали их в postgres.

логика сдвига зависела от скорости роста таблицы и объема данных. в ряде сервисов хватало общего коэффициента с запасом (например, x2-x3).
важно, что этот механизм можно было безопасно запускать многократно - при рестарте микросервиса. дополнительно была сделана административная ручка для runtime-сдвига sequence. решение легко тиражировалось между микросервисами - менялась только формула расчета нового значения.

итог: благодаря этим работам кодовая база микросервиса научилась дружить со слоном.

а о стратегии миграции исторических данных поговорю в следующей части.
💎 - жду, очень интересно!
(насыпьте пж алмазов, нужно понимать отклик такого контента)

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 2: миграция данных]

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

возможные подходы к миграции данных

а) spring batch
классический инструмент для etl-процессов (extract, transform, load).
миграция реализуется на уровне кода: несколько datasource, reader, processor, writer, job, step.

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

б) dblink
прямое подключение к oracle и перенос данных запросами.
рабочий, но достаточно низкоуровневый вариант.

в) ora2pg
утилита для миграции схемы и данных из oracle в postgresql.
хорошо подходит для одноразового переноса, но плохо ложится на сценарии с активной записью и требованиями zero-downtime.

г) fdw и утилиты поверх него (например, ora_migrator)
идея fdw - создание в postgresql «прокси»-таблиц с прямым доступом к oracle.
можно читать данные из oracle как из обычных таблиц postgresql.
утилиты поверх fdw упрощают жизнь: автоматизируют перенос данных, конвертацию типов и рутинные операции. под капотом все равно fdw, но с меньшим количеством ручной работы.

д) cdc (change data capture)
например, oracle goldengate или debezium.
идея - онлайн-репликация данных без остановки системы: изменения (insert / update / delete) сразу летят в postgresql.

плюс - идеально подходит под zero-downtime.
минус - дополнительная инфраструктура и необходимость разбираться в инструменте.

в итоге для нашего проекта остановилась на cdc.

ожидания от cdc-решения были следующие:
1. opensource или free
2. поддержка oracle → postgresql
3. начальная загрузка данных + онлайн-репликация изменений
4. возможность накатываться на уже существующие таблицы
5. поддержка преобразований данных (например, типов)

рассмотренные cdc-решения

oracle golden gate (free)
бесплатная версия умеет реплицировать только oracle → oracle, что сразу делает ее непригодной для нашего сценария.
полную версию я пыталась раскатить отдельно, но опыт оказался довольно болезненным: нормально не завелась ни на linux, ни на macos, ни на windows (пробовали разные версии). плюс очень ограниченное количество материалов вне официальной документации - в основном приходится ориентироваться на коды ошибок и мануалы.

airbyte
есть opensource-версия с активным github и платные расширения.
oracle connector от разработчиков платный, а community-версия сильно ограничена:
• нельзя управлять типами данных на конвейере
• не умеет писать в уже существующие таблицы postgresql
• не поддерживает полноценную онлайн-репликацию

по факту это скорее инструмент для разовой или периодической загрузки (cron / ручной запуск), чем полноценный cdc.

debezium
полноценный opensource с большим коммьюнити и живой экосистемой.
есть ui, но на начало 2025 он выглядел довольно сырым и практической ценности почти не нес - удобнее использовать связку kafka connect ui + kafka ui + http.

по результатам экспериментов debezium лучше всего подошел под требования проекта.
основной минус - высокий порог входа и необходимость работы с kafka-инструментарием, что добавляет сложности в поддержке.

в следующей части - продолжение
💎 - поддержка!

💻как мы переехали с Oracle на PostgreSQL без даунтайма [часть 3: процессы]

если в первой части я рассказывала о том, как в целом подготовить кодовую базу к переезду, во второй - о способе миграции данных, то в этой - к какому в итоге процессу я пришла.

про организацию релизов

в среднем за один релиз переводился один микросервис (иногда и три). такие релизы мы называли техническими - в них не было ничего, кроме миграционных изменений. они выходили между основными бизнес-релизами.

по веткам использовали следующий подход:
параллельно release-x создавалась ветка postgres-release-x с полностью идентичным кодом плюс доработки под postgresql.
эта ветка не мержилась в master до выхода в прод.

тестовый стенд велся в двух namespace:
• основной - на master
• отдельный - на postgres-ветке

это позволяло не блокировать разработку и тестирование и не тормозить бизнес-релизы из-за миграционных нюансов. cherrypick-и в релизные ветки выполнялись синхронно.

в итоге процесс на тестовом стенде выглядел так:
1. для целевого микросервиса заводилась ветка postgres-release-<version>, в которую вливались все изменения. релизные правки подтягивались через cherrypick
2. микросервис можно было деплоить сразу - ddl накатывался нативно через liquibase
3. во всех postgresql-микросервисах отключались джобы и очереди, чтобы второй namespace не перехватывал события и не писал данные неконсистентно. управление выполнялось через feature flags
4. в окружении задавались оба datasource: oracle и postgres, выполнялась синхронизация sequence
6. временно отключались fk и другие тяжелые структуры через feature flags для проведения миграции данных
7. база подготавливалась к работе с debezium
8. выполнялась миграция данных и последующее тестирование

на препроде и проде цикл был следующим:
1. подготавливалась инфраструктура
2. заранее накатывались проверенные ddl через ДБА в postgreSQL базу
3. запускался debezium для перелива снепшота и онлайн-изменений
4. микросервис деплоился на postgres-ветке: клиенты начинали работать с новой базой, а debezium в моменте догонял оставшиеся изменения из oracle, включались fk и другие тяжелые структуры

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

в следующей статье разберу debezium как инструмент и расскажу о его устройстве и тонкой настройке.
💎 - поддержка!

как думаете: расширять статью и идти на хабр? насколько интересно читать такие личные истории? чем-то полезно, даже если не ложится в рабочее?

💎- без слов да

📚обзор на ч. 3 «Предметно-ориентированное проектирование» от Эрика Эванса (Углубляющий рефакторинг)

ч.1
ч.2

рефакторинг начинает влиять на надежность и «долголетие» системы только тогда, когда опирается не на чистоту кода, а на понимание предметной области. либо узнали что-то новое о бизнесе — код меняется, либо делаем модель точнее.

микрорефакторинг и архитектурные шаблоны остаются необходимыми, но поверх них появляется углубляющий рефакторинг. его цель — не код, а модель, часто через цепочку мелких правок.

разработчик должен понимать не только что делает система, но и почему. это знание появляется через постоянный диалог со специалистами предметной области.

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

технические решения могут быть разными. хранимые процедуры, ограничения параметров и т.д. — не меняют модель, пока она не искажается. архитектура и реализация могут варьироваться, цена — удобство поддержки.

гибкая архитектура продолжает углубленное моделирование. неявные знания становятся явными — «сырье» формирует модель и архитектуру, позволяющую системе реально работать. гибкость не равна усложнению — простые, вдохновляющие архитектуры создаются дисциплинированной работой.

если для использования компонента нужно изучать реализацию — инкапсуляция не работает. имена классов и методов должны описывать назначение, тесты пишутся раньше реализации, интерфейсы описывают правила и факты, а не способы их достижения.

логика разделяется по эффектам: чистые функции без побочных эффектов, простые команды для изменений состояния, сложные вычисления — объекты-значения.

зависимости неизбежны, но лишние вредны. сильный прием упрощения — замкнутость операций: вход и выход одного типа формируют интерфейсы высокого уровня и отражают логику предметной области.

изменяемую часть процесса стоит вынести в объект — стратегию. это способ выразить правило или политику предметной области. для иерархий используется композит, отражающий операционную симметрию. flyweight — только техническая оптимизация, не шаблон для доменной модели.

итого: углубляющий рефакторинг — постоянный исследовательский процесс, оправдан, если архитектура перестала отражать понимание предметной области, важные понятия неявны или есть шанс сделать модель и архитектуру более выразительными.

💎 - спасибо!

📚обзор на ч. 4 «Предметно-ориентированное проектирование» от Эрика Эванса (Стратегическое проектирование)

ч. 1
ч. 2
ч. 3

когда сложность системы возрастает до того, что ее уже невозможно знать на уровне отдельных объектов, появляется потребность в специальных приемах для восприятия больших моделей и манипулирования ими.

единая доменная модель для большой системы почти всегда недостижима или слишком дорогая. поэтому систему делят на части — bounded contexts.

если различия долго остаются незамеченными, проявляются ошибки: интерфейсы расходятся, система ведет себя непредсказуемо, язык путает команды. особенно опасны дублирующиеся понятия и ложные родственники — одно и то же реализовано дважды или одинаковые термины скрывают разный смысл.

можно сразу обнаруживать проблемы через непрерывную интеграцию. она работает на двух уровнях: код и понятия. интеграция кода — сборка, тесты, частые слияния.
интеграция понятий — единый язык, постоянная проверка согласованности.

extreme programming хорошо поддерживает целостность модели внутри одного контекста, но между контекстами нужны архитектурные решения. варианты: shared kernel, customer/supplier, conformist, anticorruption layer.

anticorruption layer — изоляция своей модели через трансляцию. обычно комбинация фасада и адаптера: фасад упрощает внешний интерфейс, адаптер переводит вызовы и данные. слой может быть двусторонним, если обе системы обмениваются вызовами или событиями. минимальные изменения чужой системы допустимы, но осторожно.

размер контекста выбирают по задачам и команде. большой контекст удобен, когда сценарии тесно связаны, проще понять цельную модель. маленький — проще поддерживать CI, точнее отражает узкие задачи и диалект команды.

смысловое ядро выделяют в отдельный модуль (abstract core). фундаментальные понятия становятся абстрактными классами или интерфейсами, специализированные части остаются в своих модулях. большинство ссылается на ядро, а не друг на друга.

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

стратегическое проектирование начинается с оценки ситуации: карта контекстов, единый язык, смысловое ядро, технологии, навыки и интерес команды.

итого. гибкая модель даёт ясное понимание, позволяет развивать систему, решать реальные задачи и адаптироваться к изменениям.

💎- спасибо за обзор книги!