Где хранить общие услуги?

Question

В подходе, управляемом доменом. Где хранить общие службы?

Например. Иногда нам могут потребоваться общие функции, такие как getcountrylist, getstatelist, getcitylist (или некоторые другие данные из таблиц MASTER), чтобы отобразить выпадающее меню на разных страницах/модулях пользовательского интерфейса. Предположим, что эти данные присутствуют в базе данных, тогда мы должны иметь эти функции.

1. Могу ли я сохранить эти функции внутри домена/Common/CommonServices.php (я имею в виду внутренний слой домена хорошо?) (или)

   Могу ли я сохранить эти функции внутри Инфра/Общие/CommonServices.php (в этом случае мне нужно подключиться к слою dao непосредственно из слоя Infraservice, который я чувствую не так?)

2. Какое правильное имя/внушаемое имя для файла, который содержит эти общие функции. (CommonServices.php (или) CommonHelper.php (или) CommonUtils.php (или) MetadataService.php (или) любой из ваших предложений)

Answer 1

Если вам действительно нужны одни и те же данные в различных ограниченных контекстах и ​​вас получить их с тем же хранилищем, а затем в DDD есть что-то, называемое SHARED KERNEL. ШАРЕД KERNEL это место, когда вы положили вещи, которые пересекаются в нескольких ограниченных контекстах, цитата из DDD Быстрого:

The purpose of the Shared Kernel is to reduce duplication, but still keep two separate 
contexts. Development on a Shared Kernel needs a lot of care. Both teams may modify 
the kernelcode, and they have to integrate the changes. 
If the teams useseparate copies of the kernel code, they have to merge the codeas soon 
as possible, at least weekly. A test suite should be inplace, so every change done to 
the kernel to be tested right away. Any change of the kernel should be communicated 
to another team, and the teams should be informed, making them aware of the new 
functionality. 

В любом случае, если ваш ШАРЕД KERNEL становится слишком большим, то это может быть проблемой с моделированием. Постарайтесь, чтобы SHARED KERNEL был как можно меньше.

Answer 2

Поведение связано с данными, поэтому я бы поместил его в специальный репозиторий или фасад Read Model. Вы также можете воспользоваться службой домена, но служба является перегруженным термином и не передает аспект доступа к данным IMO.

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

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