противокоррупционную слоя в фасадов, Услуги и SRP

Question

1)

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

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

2)

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

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

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

I - ACL услуги являются Domain Services?

II - что доменные понятия просочились в ACL?

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

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

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

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

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

UPDATE:

1)

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

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

I. Я предполагаю, что «в» опечатка и должно быть заменено на «и»?

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

III.И если Фасад подвергало обязанность из несколько BCs, то мы должны иметь один фасаддля каждого этих внешнего BCs? Если да, то почему он предпочитает иметь один Фасад для всех BCs? Просто потому, что интерфейс Facade станет беспорядком?

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

В.

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

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

б)

Сам фасад фактически услуга или набор услуг. Нет необходимости , чтобы определить дополнительную услугу.

Хм, я не уверен, что понял это. Anyways, how do Услуги ACL map to Фасад? Возможно каждая служба ACL отображается один ответственности что наши Фасад разоблачений (т.е. если Фасад выставляет единую ответственность, то есть только один ACL службы, если он выставляет две обязанности, у нас есть две службы ACL и т. д.)?

3)

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

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

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

4)

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

Разное как?

Второе обновление:

1)

)

II.

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

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

Q2 - Так должен ли Фасад разоблачить Обязанности или примеры использования?

V.

Как правило, функциональное сцепление предпочтительнее технического или логического сцепление. Вообще, однако, у вас будут миксы обоих. Техническое решение может быть удобно при меньших масштабах. Например, вы можете использовать аналогичные механизмы сериализации или перевода на фасаде. Это удобно делиться ими между фасадами, однако не ценой функциональной связности. Поэтому вполне нормально использовать такую ​​функциональность в пределах одного BC, но не через BC.

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

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

VI. Is Функциональное сцепление никак не связано с Боковые эффекты Свободные функции/Чистые функции?

2)

б)

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

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

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

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

III.

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

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

ТРЕТИЙ UPDATE:

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

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

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

стр.367:

Фасад принадлежит в БЛ другой системы

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

спасибо

Answer 1

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

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

2a1) Да.

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

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

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

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

UPDATE

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

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

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

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

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

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

3) Да, это то, что говорит автор.

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

ОБНОВЛЕНИЕ 2

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

1a2) Я считаю, что ответственность - лучший термин.

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

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

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

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

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