Фасады, услуги и SRP антикоррупционного слоя

1)

а) Фасад ACL предлагает доступ только к тем функциям другой системы ( внешней системы или, возможно, даже другого ограниченного контекста также разработан нашей командой ), который нужен нашему BC. Если другая система предоставляет функциональные возможности (в которых заинтересован наш BC), которые мы можем разделить на несколько разных обязанностей, следует определить одну Фасад ACL для каждой из этих обязанностей или у нас должен быть один Фасад ACL, раскрывающий все обязанности (предлагаемые внешним system ), который нужен нашему BC?

б) Если ответ на вопрос a) состоит в том, что мы должны определить один фасад ACL для каждой из функций, предлагаемых внешней системой, должны ли мы, в свою очередь, также определить один ACL Сервис для каждого фасада ACL?!

2)

а) Книга Эвана (стр. 366):

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

Сам ACL не находится внутри уровня домена, но, согласно приведенной выше цитате, службы ACL не представляют концепции домена? Если да, то не можем ли мы утверждать, что:

I - службы ACL являются доменными службами?

II - что концепции домена просочились в ACL?

б) Какова ответственность службы ACL? Просто в качестве посредника между нашей BC и внешней системой (т. е. другой BC ) или может служба ACL иметь < em>ответственность отличается от ответственности, предлагаемой внешней системой, и поэтому служба ACL может использовать функции, предлагаемые внешней системой только для выполнения собственных назначенных задач?

3) Книга Эвана (стр. 366):

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

Говорит ли автор, что не имеет смысла представлять внешнюю систему как имеющую одну ответственность, но вместо этого систему можно представить как имеющую несколько обязанностей, и поэтому мы должны определить фасад ACL + службу ACL (и соответствующий адаптер) для каждой из этих обязанностей?

4) Кстати, я предполагаю, что ACL также может быть определен между двумя ограниченными контекстами, существующими в одном приложении и разработанными одной и той же командой?

ОБНОВЛЕНИЕ:

1)

а) Я не совсем понимаю ваши рассуждения:

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

I. Я предполагаю, что «в» — это опечатка и ее следует заменить на «и»?

II. Под «различные обязанности по-прежнему попадают в один и тот же ограниченный контекст» вы имеете в виду тот факт, что Facade раскрывает только обязанности одиночная БК?

III. А если Facade возлагал на обязанности несколько бизнес-концепций, то у нас должен быть один Facade для каждого< /strong> этих внешних BC? Если да, то почему он предпочтительнее, чем один Facade для всех BC? Просто потому, что интерфейс Facade стал бы беспорядочным?

IV. Под "Если фасад используется одним и тем же проектом" вы подразумеваете, что если оба BC являются частью одного и того же приложения, тогда мы должны использовать < em>один фасад, чтобы показать все обязанности? А что, если другой BC принадлежит другому приложению?

V.

Преимущества технической сплоченности по оси API внешней системы перевешивают преимущества функциональной связанности по оси ответственности.

Почему техническое единство предпочтительнее функционального взаимодействия?

b)

Фасад сам по себе является услугой или набором услуг. Нет необходимости определять дополнительную услугу.

Хм, я не уверен, что понял это. В любом случае, как службы ACL сопоставляются с Facade? Возможно, каждая служба ACL сопоставлена ​​с одной обязанностью, которую предоставляет наш Фасад (например, если Фасад предоставляет одна ответственность, то у нас есть только одна служба ACL, если она предоставляет две обязанности, у нас есть две службы ACL и т. д.)?

3)

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

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

Должен признаться, я еще не слушал Удивительное определение ролей, так что я немного запутался, но я не имел в виду, что мы должны добавить дополнительную службу ACL для каждой уже имеющейся у нас службы ACL. Вместо этого я спрашивал, имел ли автор в виду, что у нас должна быть одна служба ACL для каждой ответственности (т. е. если другая BC/Facade имеет одну ответственность, мы следует определить одну службу ACL, если она имеет две обязанности, мы должны определить две службы ACL и т. д.)

4)

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

Как по-другому?

ВТОРОЕ ОБНОВЛЕНИЕ:

1)

a)

II.

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

Вопрос 1 – вы используете термин "вариант использования" вместо ответственность. Правильно ли я предполагаю, что фраза «Фасад предоставляет один вариант использования» обычно предполагает, что Фасад предоставляет единственный метод, в то время как утверждение «Фасад предоставляет единая ответственность" также может означать, что Facade предоставляет несколько методов (которые вместе выполняют определенную задачу)?

Q2. Итак, должен ли Фасад раскрывать обязанности или варианты использования?

V.

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

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

Но мне сложнее представить себе сценарий, когда внешняя система (и, следовательно, Фасад) выставляет только одну ответственность — даже в таком возможно ли спроектировать Фасад таким образом, чтобы он имел техническое единство, а не функциональное единство? Если да, не могли бы вы привести простой пример?

VI. Связана ли функциональная связность с функциями без побочных эффектов / чистыми функциями?

2)

b)

В любом случае, как сервисы ACL сопоставляются с Facade? Возможно, каждая служба ACL сопоставлена ​​с одной обязанностью, которую предоставляет наш Facade (т. е. если Facade предоставляет одну ответственность, то у нас есть только одна служба ACL, если она предоставляет две обязанности, у нас есть две службы ACL и т. д.)?

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

I. Я думаю, что понимаю, что вы имеете в виду, но просто для уверенности - если предположить, что наш BC обменивается данными только с одной внешней системой, и поэтому у нас есть только один Фасад, Фасад обычно реализуется как одиночный класс?

II. Кстати, я предполагаю, что службы ACL не вызывают этот фасад напрямую, а вместо этого вызывают методы соответствующих адаптеров, которые, в свою очередь, вызывают методы для этого Фасада?

III.

И да, ваше предположение является приемлемым способом сделать это.

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

ТРЕТЬЕ ОБНОВЛЕНИЕ:

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

Насколько я понимаю ваши ответы, вы, по сути, говорите, что службы ACL составляют Фасад, а это означает, что эти службы ACL представляют интерфейс Фасада? Это также подразумевало бы, что Facade принадлежит нашему BC, поскольку он выражается в терминах модели предметной области нашего BC (причина в том, что службы ACL выражены с точки зрения модели предметной области нашей Британской Колумбии )?!

Но Эванс утверждает, что Facade относится к BC другой системы (и как таковой должен быть выражен с использованием концепций предметной области внешней системы), в то время как Службы ACL должны принадлежать нашему BC и поэтому должны быть выражены с использованием понятий домена нашего BC:

pg. 367:

Фасад относится к БЦ другой системы

Так я неправильно понял ваш пост или ваше мнение по этому вопросу немного отличается от мнения Эванса?

Спасибо


person user437291    schedule 18.02.2013    source источник


Ответы (1)


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

1b) Фасад сам по себе является услугой или набором услуг. Нет необходимости определять дополнительную услугу.

2а1) Да.

2a2) Да, однако я бы не назвал утечку в уничижительном смысле. Цель ACL — адаптировать внешнюю модель к локальной модели предметной области. Поэтому, естественно, там будут доменные понятия.

2b) Служба ACL должна быть только посредником между внешней системой и вашим BC. Однако природа этого посредничества может быть расширена. Основная цель — защита от коррупции, которая может возникнуть в результате изменений во внешней модели.

3) Да, внешняя система может играть разные роли в вашей системе. Таким образом, он может быть представлен в ACL как несколько служб. Нет необходимости определять дополнительную службу для каждой службы ACL — они уже являются службами.

4) Правильно. Однако отношения между двумя БК, развитыми локально, могут быть иными, чем во внешней системе.

ОБНОВЛЕНИЕ

1а1) Да, опечатка. Исправленный.

1a2) Фасад инкапсулирует API внешней системы. Если функциональные возможности, предоставляемые API, используются только одним BC, но есть несколько вариантов использования, то можно иметь один фасадный сервис для этого BC. Альтернативой является создание фасада для каждого варианта использования. Это тоже хорошо, но, как я уже сказал, техническая связность первого подхода может быть полезной.

1а3) В этом случае в каждом БЦ был бы фасад. Альтернативой было бы попытаться поделиться фасадом. Как вы сказали, это станет беспорядком зависимостей.

1а4) Да. Если другой BC является частью другого приложения, создайте новый фасад, специфичный для этого BC, как указано в 1a3.

1a5) Обычно функциональная связность предпочтительнее технической или логической. Однако, как правило, у вас будет смесь обоих. Техническая сплоченность может быть удобной в меньших масштабах. Например, вы можете использовать аналогичные механизмы сериализации или трансляции в фасаде. Их удобно делить между фасадами, но не за счет функционального единства. Таким образом, можно совместно использовать такую ​​функциональность в рамках одного бизнес-контейнера, но не между бизнес-контейнерами.

2b) ACL — это фасад, состоящий из сервисов. И да, ваше предположение является приемлемым способом сделать это. Термин «фасад» здесь относится не к одному классу, а к набору классов (сервисов), составляющих уровень защиты от коррупции. Это может быть только один класс, или их может быть много.

3) Да, именно об этом говорит автор.

4) Это также обсуждается в последующих разделах книги. Отличие локальных BC может заключаться в том, что команды, разрабатывающие их, могут общаться, и это настраивает их модели для выполнения требований друг друга. Для внешних БК это может быть невозможно.

ОБНОВЛЕНИЕ 2

1a1) Термин «вариант использования» должен был быть взаимозаменяемым с «ответственностью». Они могут означать один метод или несколько.

1a2) Я думаю, что лучше использовать термин «ответственность».

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

VI.) Нет. Это просто тип сплоченности, который выравнивается по домену под рукой, в отличие от некоторых технических аспектов.

2b1) У вас будет один класс, который реализует доменную службу, которая предоставляет внешний BC локальному BC. Однако этот класс может использовать другие классы, например, для сериализации или чего-то еще. Однако эти классы «спрятаны» за этим классом обслуживания.

2b2) Службы ACL составляют фасад. Это может быть просто путаница в терминологии. ACL — это фасад.

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

person eulerfx    schedule 18.02.2013