komponowanie wielu ograniczonych kontekstów w jednym interfejsie użytkownika,

Rozwijamy system, który składa się z wielu ograniczonych kontekstów, istnieją interfejsy użytkownika, w których wyświetlane informacje muszą być renderowane z wielu ograniczonych kontekstów.komponowanie wielu ograniczonych kontekstów w jednym interfejsie użytkownika,

Klasycznym przykładem takiego interfejsu jest strona zamówienia Amazon.com. Tam, gdzie widzimy produkt (produkt BC), dostępne zapasy magazynowe (Inventory BC), ceny i tak dalej.

Moje pytanie: w takich scenariuszach, w których ograniczonym kontekście byłby interfejs użytkownika? Dostaję, jak możemy pobierać dane z wielu BC w celu utworzenia strony, ale czy istnieją jakieś wskazówki, gdzie powinna znajdować się sama strona?

Podobne pytania here i here, zajmują się tym, jak uzyskać informacje z wielu BC, ale nie podają adresu BC, w którym sam interfejs użytkownika będzie mieszkać?

Wszelkie wytyczne dotyczące tej kwestii na przykładzie byłoby świetnie ...

Źródło

2014-09-29 Sudarshan

Jak zorganizowałeś kod źródłowy na końcu? Czy masz jedną aplikację internetową dla wszystkich kontekstów ograniczonych lub jednej aplikacji internetowej na kontekst odesłany? Jeśli to drugie, czy używałeś obszarów mvc? +1. – w0051977

Nie jestem ekspertem, ale uważam, że interfejs nie mieszka w BC. Interfejs użytkownika jest wyrażeniem jednej lub więcej BC. BC jest granicą wokół decyzji, które są ze sobą powiązane. W jaki sposób ujawnić to użytkownikowi, nie jest to problemem.

Na przykład masz stronę internetową, taką jak amazon.com z kilkoma BC, tak jak mówisz, interfejs użytkownika prowadzi cię po prostu pomagając ci podejmować decyzje w dowolnym BC, w którym jesteś zaangażowany.

Ostatnia próba. Jeśli wyobrazisz sobie schemat sześciokątnej architektury lub warstwowej architektury, będziesz miał na samym wierzchu (u góry) jakiś UI. Komunikowałby się z warstwą antykorupcyjną (lub usługą aplikacji). To A-C będzie następnie delegować do właściwego BC, aby obsłużyć polecenie, które chcesz spełnić.

Źródło

2014-09-29 20:20:08 Raif

Tak, to jest dla mnie nowa linia myślenia: dobrze, jeśli powiemy, że każdy BC był repozytorium w Github lub dowolnym VCS, to gdzie fizycznie mógłby kłamać interfejs użytkownika? – Sudarshan

cóż, najpierw odradzam segregację lub przedwczesną dystrybucję. Jeśli twój system potrzebuje tego, to świetnie, ale jeśli nie, to dodając złożoność bez powodu, dodajesz te funkcje, gdy zajdzie taka potrzeba. Po drugie, używam .net, możesz mieć repozytorium, które zawiera tylko twoją aplikację internetową i utrzymuje połączenie z BC za pośrednictwem wiadomości lub bezpośrednich odnośników dll, lub jeśli masz wszystkie projekty w jednym repo, możesz dołączyć projekty, które potrzebujesz w Twojej aplikacji internetowej. – Raif

Pomyślałem o tym, jednak oznaczałoby to, że wszystkie widoki znajdują się w webappie, a repozytorium odnoszące się do każdego BC nie będzie miało żadnej reprezentacji UI (widoki). Chciałbym, żeby te BC były oferowane jako niezależne oprogramowanie, a więc chcą, aby widoki związane z każdym z BC znajdowały się w repozytorium BC – Sudarshan

Interfejs użytkownika ma swoje własne obawy i wzorce współpracy; to jest BC sama w sobie.

Źródło

2014-10-02 15:06:25

BC jest raczej terminem konceptualnym DDD, prawdopodobnie użyłem go w niewłaściwym kontekście ... Próbuję dowiedzieć się, jak podzielić kod źródłowy na podstawie BC ... Myślę, że w wielu przypadkach ma repozytorium na BC jest uczciwa umowa. Stamtąd próbuję dowiedzieć się, gdzie powinny znajdować się interfejsy użytkownika, które tworzą informacje z wielu BC ... – Sudarshan

komponowanie wielu ograniczonych kontekstów w jednym interfejsie użytkownika,

Odpowiedz

Powiązane problemy