Использование повсеместного языка в аргументах сервисов приложений

Question

Вездесущий язык (UL) используется в ограниченном контексте, как модели предметной области, так и уровня приложений, верно?Хорошо.Тогда имя методов службы приложения принадлежит UL.Но аргументы метода, поскольку доменные объекты не должны быть доступны пользователям, не будут (не могут) быть терминами из UL.Если бы вы использовали словарь UL для именования аргументов метода, то вы бы выставляли доменные объекты вне приложения.

Как вы объясните это противоречие с именами параметров служб приложений?

Может быть, вопрос кажетсянемного философский, но так же как и DDD, это философия разработки программного обеспечения, основанная на UL.

ОБНОВЛЕНИЕ

Кто-то спросил пример, а не только философию.Ну, скажем, наш домен о магазине по продаже товаров.Одним из методов службы приложений может быть:

addProductToShoppingCart (Product product, ShoppingCart shoppingCart);

Но Product и ShoppingCart являются объектами / объектами-значениями модели домена, и мы не должны раскрыватьэто клиентам.

Таким образом, аргументы должны быть DTO или примитивными типами.Но такие типы не относятся к UL.Product и ShoppingCart принадлежат UL и должны быть аргументами метода, но, делая это, вы нарушаете правило предоставления домена клиентам.

Answer 1

Пример будет гораздо лучше обсуждать, чем просто «философия».Но ..

Противоречие состоит в том, что большинство конструкций DDD на самом деле не следуют UL достаточно строго.Посмотрите практически на любой общедоступный дизайн «DDD», например репозиторий Вона Вернона Github .

«Домен» (то есть объекты-значения и объекты) обычно моделируются как объекты только для данных", с небольшой, если вообще какой-либо бизнес-логикой.Прямо там имена методов уже покинули UL и находятся исключительно в технической среде (обычно сеттеры, геттеры).

То же самое с Сервисами.Услуги являются не частью «Домена» вообще.Попробуйте рассказать деловому человеку, что вы внедрили PasswordService, я гарантирую пустой взгляд.Внешние сервисы также носят чисто технический характер, с некоторыми бизнес-методами, которые на самом деле могут принадлежать какому-либо объекту или объекту значения.

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

Взгляните на мою презентацию, посвященную именно этой проблеме: https://speakerdeck.com/robertbraeutigam/object-oriented-domain-driven-design

Answer 2

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

"Если выиспользовал словарь UL для именования аргументов метода, тогда вы бы выставили доменные объекты вне приложения.Типы рычагов, определенные в пакете домена.Это только по техническим причинам, так как это разделение позволяет изменять модель домена независимо от API общедоступного приложения.