Как правильно реализовать bounded context городов?

Question

[Dos]

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

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

Если правильно понимаю bounded context, то там говорится о том, что в каждом контексте свои сущности. В моём случае в разных контекстах используется город. Но города синхронизировать в каждом контексте такая себе идея. У меня возникло три варианта решения моей задачи:

1. Вынести города в отдельный ГЕО контекст и в других контекстах использовать только id городах контекста ГЕО. В контекст ГЕО данные будут добавляться из API стороннего сервиса.
2. Поместить в каждый контекст свои города, страны, регионы.
3. Поместить город в сущность, которой он требуется вместо ID города. Но тут вопрос нормализации.

Подскажите, как лучше поступить? Какие есть хорошие практики? Расскажите как сами подходите в подобной ситуации.

Всем спасибо!

Answer 1

[DarkTM]

По-моему, тут очевидный 1 вариант, выпилить с проекта города в отдельную сущность, со своим api, и отдавать города и адреса.
Во втором и третьем варианте, сразу видится проблема DRY, если в нескольких контекстах повторяются города и методы для них.
Вообще это азы... вроде как... хотя может только и для меня, но если у вас в проекте, что-то повторяется в нескольких местах, то это нужно вынести в отдельную сущность, работать как с отдельным модулем со своим API. Проще написать единое API, для всех городов и обработчик внутри каждого домена которому нужна эта сущность, и дополнять по необходимости, чем реализовывать одно и тоже в каждом.

Comments

[Dos]

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

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

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

По сути я мог бы вынести в общий контекст например Клиентов, так как он используется в разных контекстах. Так же выношу города, организации. В итоге во всех контекстах много появляется ID без самих данных.

Как в итоге стоит подходить к этому всему? Где этому можно поучиться. Что почитать.

[DarkTM]

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

[Dos]

DarkTM, ну вот тогда такой вопрос. У меня есть мероприятия. В них могут быть участники, наставники, организаторы, волонтеры. Как это можно назвать одним словом? Участники? Но не подходит. В мероприятии каждый может быть любым типом. Как их связывать?

Это мы рассматриваем только контекст мероприятия. А есть контекст CRM. В которых есть клиент. Как мне его связывать со всеми типами выше?)

[DarkTM]

Dmitry, Отвечая на ваши вопросы, могу сказать так, перестаньте запутывать меня и себя.
Bounded Context - Это граница предметной области в рамках которой, происходит некий бизнес процесс. Не поняв бизнес процессы мероприятия, сказать о том являются организаторы, участники и волонтеры одной сущностью, нельзя. Так как контекст требует четкой предметной области и четких терминов, а не расплывчатой абстракции. Например в случае городов, они части координат некого объекта на карте, и даже если они участвуют в одном бизнес процессе, они будут отдельной сущностью, так как обладают всем необходимым для этого набором свойств, что бы иметь свою. собственную предметную область и её границы.
В случае мероприятия, не очень понятно кто чем занимается, но чисто абстрактно, они все являются сущностью "Участники", с заданными для себя свойствами, под каждую роль. На практике, я уже писал, идеального контекста не бывает, так как все упирается в бизнес процессы и язык которым они описаны.
Как их увязать между собой, может ответить только бизнес процесс, а не абстрактная серебряная пуля. Так как именно бизнес процесс, как то их увязывает между собой и клиентом в реальности.

[Dos]

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

Поэтому я и не могу разобраться в этом вопросе. Всю голову сломал уже. Хочется разобраться и сделать правильно предметную область. Так как Прототип уже был.

А у вас есть хороших опыт в проектировании ддд? Может взять у вас консультацию. Все равно «страдаю фигней»)))