1)
a) ACL Facade предлага достъп само до онези функции на другата система ( външна система или може би дори друг Ограничен контекст > също разработено от нашия екип), от което нашият BC се нуждае. Ако друга система разкрива функционалност (от която нашият BC се интересува), която можем да категоризираме в няколко различни отговорности, трябва ли да дефинираме една ACL фасада за всяка от тези отговорности или трябва да имаме единична ACL фасада, излагаща всички отговорности ( предлагани от външни система ), от които нашият BC се нуждае?
b) Ако отговорът на a) е, че трябва да дефинираме една ACL фасада за всяка от отговорностите, предлагани от външната система, трябва ли на свой ред също да дефинираме една ACL Услуга за всяка ACL фасада?!
2)
a) Книгата на Евън (стр. 366):
Публичният интерфейс на антикорупционния слой обикновено се появява като набор от услуги... Може дори да няма смисъл в нашия модел да представяме външната система като един компонент. Може би е най-добре да използвате множество услуги, всяка от които има съгласувана отговорност по отношение на нашия модел
Самият ACL не се намира в рамките на Слоя на домейна, но според горния цитат ACL услуги не представляват концепции на домейн em>? Ако е така, не можем ли да спорим, че:
I – ACL услугите са Услуги за домейни?
II - че концепции за домейн са изтекли в ACL?
б) Каква е отговорността на ACL услугата? Просто за посредничество между нашия BC и външна система (т.е. друг BC ) или може ACL Service да има < em>отговорност, различна от отговорност, предлагана от външна система, и като такава ACL услуга може да използва функционалност, предлагана от външна система само за изпълнение на свои собствени определени задачи?
3) Книгата на Евън (стр. 366):
Публичният интерфейс на антикорупционния слой обикновено се появява като набор от услуги... Може дори да няма смисъл в нашия модел да представяме външната система като един компонент. Може би е най-добре да използвате множество услуги, всяка от които има съгласувана отговорност по отношение на нашия модел
Авторът казва ли, че може да няма смисъл да се представя външна система като носеща единствена отговорност, но вместо това тази система може да бъде представена като имаща няколко отговорности и като такива бихме дефинирали ACL Facade + ACL услуга (и съответния Адаптер) за всяка от тези отговорности?
4) Между другото - предполагам, че ACL може да се дефинира и между два ограничени контекста, съществуващи в едно и също приложение и разработени от един и същи екип?
АКТУАЛИЗАЦИЯ:
1)
а) Не разбирам напълно мотивите ви:
Ако фасадата се използва от един и същ проект и отделните отговорности все още попадат в същия ограничен контекст, тогава използвайте същата фасада. Ползите от техническото сближаване по оста на API на външната система ще надделеят над ползите от функционалното свързване по оста на отговорността.
I. Предполагам, че „в“ е правописна грешка и трябва да се замени с „и“?
II. Под „отделните отговорности все още попадат в същия ограничен контекст“ имате предвид факта, че Фасадата разкрива само отговорностите на единичен пр.н.е.?
III. И ако Фасадата разкриваше отговорностите на няколко BC, тогава трябваше да имаме една Фасада за всеки< /strong> от тези външни BC? Ако да, защо се предпочита пред наличието на една фасада за всички BCs? Просто защото интерфейсът на фасадата би станал бъркотия?
IV. Под „Ако фасадата се използва от един и същ проект“ имате предвид, че ако и двата BC са част от едно и също приложение, тогава трябва да използваме < em>една фасада за излагане на всички Отговорности? И какво, ако другият BC принадлежи на различно приложение?
V.
Ползите от техническото сближаване по оста на API на външната система ще надделеят над ползите от функционалното свързване по оста на отговорността.
Защо техническото сближаване е предпочитано пред функционалното свързване?
b)
Самата фасада всъщност е услуга или набор от услуги. Няма нужда да определяте допълнителна услуга.
Хм, не съм сигурен, че разбрах това. Както и да е, как ACL услугите се свързват с Фасада? Може би всяка ACL услуга е свързана с една отговорност, която нашата Фасада излага (т.е. ако Фасадата излага единична отговорност, тогава имаме само една ACL услуга, ако излага две отговорности, имаме две ACL услуги и т.н.)?
3)
Авторът казва ли, че може да няма смисъл да се представя външна система като носеща една единствена отговорност, но вместо това тази система може да бъде представена като имаща няколко отговорности и като такава бихме дефинирали ACL Facade + ACL услуга (и съответния адаптер) за всяка от тях отговорности?
Да, външната система може да играе различни роли във вашата система. Като такъв, той може да бъде представен като множество услуги в ACL. Няма нужда да дефинирате допълнителна услуга за всяка ACL услуга - те вече са услуги.
Трябва да призная, че все още не съм слушал Udi's Making Roles explicit, така че някак съм изгубен тук, но не съм намеквал, че трябва да добавим допълнителна ACL услуга за всяка ACL услуга, която вече имаме. Вместо това питах дали авторът има предвид, че трябва да имаме една ACL услуга за всяка отговорност (т.е. ако другият BC/Facade има една отговорност, ние трябва да дефинира единична ACL услуга, ако има две отговорности, трябва да дефинираме две ACL услуги и т.н.)
4)
Правилно. Въпреки това, връзките между два БК, разработени локално, може да са различни от тези на външната система.
Различно как?
ВТОРА АКТУАЛИЗАЦИЯ:
1)
a)
II.
Фасадата капсулира API на външна система. Ако функционалността, предоставена от API, се използва само от един BC, но има множество случаи на употреба, тогава е добре да имате една услуга за фасада за този BC. Алтернативата е да се създаде фасада за всеки случай на употреба. Това също е добре, но както казах, техническото сближаване на първия подход може да бъде от полза.
Q1 – Вие използвате термина „случай на употреба“ вместо Отговорност. Прав ли съм, като приемам, че казвайки „една фасада излага единичен случай на употреба“ обикновено предполага, че фасадата излага един метод, докато казва „една фасада излага единична отговорност" може също да означава, че Facade излага няколко метода (които заедно изпълняват определена задача)?
Q2 – Така че трябва ли една фасада да разкрива отговорности или случаи на употреба?
V.
Обикновено функционалната кохезия се предпочита пред техническата или логическата кохезия. Като цяло обаче ще имате смеси и от двете. Техническото сближаване може да бъде удобно в по-малки мащаби. Например, можете да използвате подобни механизми за сериализиране или превод във фасада. Удобно е да ги споделяте между фасадите, но не за сметка на функционалното сближаване. Следователно е добре да споделяте такава функционалност в рамките на един BC, но не и между BC.
От разстояние единствена фасада с техническа кохезия, а не функционална кохезия, има смисъл. Но става доста объркващо как изглежда този процес на практика. За да обясним, ако приемем, че външната система излага няколко отговорности, тогава можем да проектираме Фасада така, че да има по-скоро Техническа кохезия това Функционално сближаване просто чрез наличие на единствена фасада, разкриваща всички отговорности, предлагани от външна система.
Но ми е по-трудно да си представя сценарий, когато външната система (и следователно Фасадата) излага само единствена отговорност – дори е в такава възможен сценарий за проектиране на фасада по такъв начин, че да има техническа кохезия, а не функционална кохезия? Ако да, можете ли да предоставите прост пример?
VI. Свързано ли е Функционалното сближаване по някакъв начин с Функциите без странични ефекти / Чистите функции?
2)
b)
Както и да е, как ACL услугите се съпоставят с Facade? Може би всяка ACL услуга е съпоставена с една отговорност, която нашата Facade излага (т.е. ако Facade излага една отговорност, тогава имаме само една ACL услуга, ако излага две отговорности, имаме две ACL услуги и т.н.)?
ACL е фасада, състояща се от услуги. И да, вашето предположение е приемлив начин да го направите. Терминът фасада тук не е предназначен да се отнася до един клас, а набор от класове (услуги), съставляващи антикорупционния слой. Може да е само един клас или може да са много.
I. Мисля, че разбирам какво намекваш, но само за да съм сигурен - ако приемем, че нашият BC комуникира само с една външна система и като такава имаме само една фасада, Фасадата обикновено ли се изпълнява като единичен клас?
II. Между другото, предполагам, че ACL услугите не извикват директно тази фасада, а вместо това извикват методи на съответните адаптери >, които от своя страна извикват методи на тази фасада?
III.
И да, вашето предположение е приемлив начин да го направите.
Така че вие по същество предполагате, че ако външната система излага две отговорности, трябва да имаме единствена фасада, излагаща и двете отговорности >, но от друга страна трябва да имаме две ACL услуги, по една за всяка Отговорност?
ТРЕТА АКТУАЛИЗАЦИЯ:
Отговорите ви много ме объркаха, така че преди да мога да задам смислени въпроси в отговор на вашите отговори (и в тази, и в другата тема, която направих), трябва да ви попитам следното:
Доколкото разбирам отговорите ви, изглежда, че по същество казвате, че ACL услугите съставляват Фасадата, което означава, че тези ACL услуги представляват интерфейса на фасадата? Което също би означавало, че Фасадата принадлежи на нашия BC, тъй като е изразена от гледна точка на домейн модела на нашия BC (причината е, че ACL услугите са изразени по отношение на домейн модела на нашия BC )?!
Но Евънс твърди, че Фасадата принадлежи към BC на другата система (и като такава трябва да бъде изразена с помощта на домейн концепции на външна система), докато ACL услугите трябва да принадлежат към нашия BC и като такива трябва да бъдат изразени с помощта на концепциите за домейн на нашия BC:
pg. 367:
Фасадата принадлежи към BC на другата система
И така, погрешно ли съм разбрал публикацията ви или мнението ви по темата е малко по-различно от това на мнението на Евънс?
Благодаря ти
