DDD и ограниченные контексты

Моделирование по философии Domain Driven Design. Понятие доменной модели. Исследование предметной области и выделение ограниченных контекстов.

Скрытый контент
Комментарии (17)
Arunas

Спасибо.

Ответить
Denis

Это прекрасно.

Ответить
Ruslan

Стало еще лучше, появились картинки :) . Мне не хватало рисунков в разработке рабочего места и деплоя. Прожал на будущую кнопку "лайк".

Ответить
Руслан

Спасибо, все лаконично и этим круто, и отдельное спасибо за kleki. Также недавно открыл для себя draw.io, удобно набрасывать схемки клиенту с любого устройства.

Ждем с нетерпением картинок с кодом :)

Ответить
BMWist

Спасибо!!! А почтовый сервер будет подниматься в этом мастер-классе или будут заглушки?

Ответить
Дмитрий Елисеев

Будут заглушки для девелопмента.

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

Ответить
Arunas

Да, было бы круто почтовый сервер (напр. image: tvial/docker-mailserver:latest) и UI с ROUNDCUBEMAIL_DB_TYPE=pgsql....

Ответить
Александр

Спасибо, Дмитрий.

Ответить
Роман

Спасибо за подробно изложенный материал!

Ответить
Максим

Доброй ночи, Дмитрий! С праздником 9 мая!)

Проектируя по DDD ограниченными контекстами решил выделить все справочники в отдельный контекст: Справочники (Dictionaries). И появилось несколько вопросов:

  1. Уместно ли такое название для справочников? Какое название используете вы?
  2. В справочник у меня ушли: категории мероприятий, категории организаций, страны регионы города, пол человека и так далее. В других сервисах я ссылаюсь на этот справочник только по ID (Category ID). Правильно ли это? Вы говорили, что сервис должен быть полностью независим. А тут вроде как зависимость. если не сложно - поясните)
Ответить
Дмитрий Елисеев

В других сервисах я ссылаюсь на этот справочник только по ID (Category ID). Правильно ли это?

Правильно. Должно быть только указание ID. Это не связь с самим объектом.

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

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

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

Ответить
Максим

Благодарю! А если категории мероприятий используется в двух местах?

Ответить
Дмитрий Елисеев

Тогда уже можно вынести.

Ответить
Максим

Отлично. Это уяснил. Дмитрий, ещё появился такой интересный вопрос. Думаю, будет интересно будет услышать этот ответ на вопрос в вашем уроке по проектированию доменных сущностей.

В своих уроках вы часто используете в качестве ID - UUID. Но везде использовать UUID не даёт понимания при анализе базы данных. Поэтому некоторые ID формируют более смысловые. Например первый символ может быть Первой буквы названия сервиса. Или используя сущность + другие значения. В итоге из тематики медицины есть такой пример: PatientTHX1138

Если не сложно включите небольшой разбор в свои лекции про генерацию UUID, а так же как это можно делать на системах, которые уже работают. На сколько знаю ID не меняется, как и не удаляются данные, из-за соблюдения консистенции данных. В таком случае придётся делать поле CODE, если правильно мыслю)

И можно ли использовать SLUG в качестве ID? Только вот проблема. Слуг иногда меняется. Например у пользователя или организации.

Ответить
Дмитрий Елисеев

Но везде использовать UUID не даёт понимания при анализе базы данных. Поэтому некоторые ID формируют более смысловые.

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

Например первый символ может быть первой буквой названия сервиса.

А потом вдруг захочется переименовать сервис и такие идентификаторы придётся тоже переименовывать.

В итоге из тематики медицины есть такой пример: PatientTHX1138. И можно ли использовать SLUG в качестве ID?

Это всё определяет вопрос, какой идентификатор использовать: суррогатный (UUID, Auto Increment) или естественный (slug, email, patient). В случае суррогатного его формат не важен и значение точно никогда не изменится.

А с пользовательскими уже сложнее. Например, для записи PatientTHX1138 таблицу patients можно создать с составным первичным ключом (id=1138, type=TNX).

Так что либо UUID или Auto Increment, либо что-то своё, либо хранить одновременно UUID для связей + что-то другое вроде slug для отображения посетителю.

Ответить
Максим

И ещё забыл уточнить. Важный момент. У меня много категорий для мероприятий, для организаций, для дисциплин. У меня есть два пути: 1. В категории добавить type и указывать (type = events, discipline, organization). В этом случае большой плюс, что не надо будет городить много сущностей, верстки и т.п. 2. Каждая категория отдельно, но так как большинство будут использоваться в 2-х и более местах придется поместить в справочник. Тогда будут названия сущностей вроде EventCategory OrganizationCategory...

Какой подход 1 или 2 лучше?

Ответить
Дмитрий Елисеев

Если разделять, то больше гибкости, так как можно программировать их со своими нюансами независимо. В этом случае проблема лишней вёрстки и кода частично решается разработкой общих виджетов и сервисов, работающих с interface Category или TreeCategory и подобными обобщениями. Если не разделять, то сэкономим на коде, но везде будем таскать type. Так что вопрос выбора сложный.

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий