Czy pokazywać API Gateway w modelu C4

Próbuję ogarnąć C4 i nie za bardzo rozumiem jaki poziom szczegółowości jest potrzebny w poziomie Containers, Mam mikroserwisy, które coś robią (biznesowego), mam też osobną usługę w postaci API Gateway i wydaje mi się, że umieszczenie go na diagramie zaciemnia obraz całości, bo wszystkie akcje, od wszystkich aktorów trafiają najpierw do gateway'a, co oznacza, że nie da się odczytać, która konkretnie usługa odpowiada za realizację jakiejś akcji biznesowej typu "wystaw fakturę".
Pytanie w skrócie, czy diagram powinien być uproszczony: (bez istotnego kontenera):

Czy raczej pełny, ale kosztem czytelności:

A jakie ma wady dodanie API gateway do modelu? Bo ja nie widzę specjalnie żadnych.

Jak dla mnie API Gateway to jest raczej już szczegół implementacyjny i na takim diagramie można to spokojnie pominąć. Użytkownik składa zamówienie w order service, a to, że po drodze przechodzi przez API Gateway nie jest raczej istotne patrząc z biznesowego punktu widzenia. Na przedstawionym diagramie czytelność jest jeszcze ok, ale im więcej klocków będziesz miał, tym mniej czytelny taki diagram będzie.

Riddle napisał(a):

A jakie ma wady dodanie API gateway do modelu? Bo ja nie widzę specjalnie żadnych.

Nie widać który aktor inicjuje jakąś funkcjonalność biznesową za pomocą której konkretnej usługi schowanej za API Gateway'em

piotrpo napisał(a):

Riddle napisał(a):

A jakie ma wady dodanie API gateway do modelu? Bo ja nie widzę specjalnie żadnych.

Nie widać który aktor inicjuje jakąś funkcjonalność biznesową za pomocą której konkretnej usługi schowanej za API Gateway'em

Możesz przedstawić jeden Api Gateway jako dwa bloczki (mimo że to jest ten sam serwis).

Albo możesz go nie pokazać w ogóle, ale wtedy on tam będzie implicitly, tylko że schowany.

No albo możesz narysować dodatkowe strzałki, które pokazują flow konkretnego aktora.

@dargenn: Tylko problem w tym, ze C4 to Context (gdzie środek tego systemu jest jednym black boxem), Containers (czyli już technicznie, to co rysuję wyżej), Components, gdzie rozpisywany jest na kawałki każdy z kontenerów i Code, czyli klasy, sekwencje.
Zastanawiam się, czy nie byłoby sensownie dać "z boku" API gateway, z informacją, że wszystko co tam jest leci przez ten blok, ale został pominięty ze względu na czytelność

Mam wrażenie, że problem jest w medium, a nie w treści.
Jeśli rysujemy statyczne diagramy, to trzeba podejmować takie decyzje.
Rozwiązaniem mogłoby być użycie jakiegoś interaktywnego toola, który by pozwalał na wyświetlanie różnych poziomów szczegółowości. Wtedy przy oglądaniu takiego diagramu można było kliknąć checkboxy, ile szczegółów z infrastruktury byłoby widoczne, a ile ukryte (ale czy ktoś zna taki tool, który pozwala na to out of the box?).

Nie widać który aktor inicjuje jakąś funkcjonalność biznesową za pomocą której konkretnej usługi schowanej za API Gateway'em

Niekoniecznie. Możesz zrobić jedną strzałkę, która będzie przechodzić przez API Gateway. Potraktować API Gateway jako pewne wizualne miejsce/chmurkę na diagramie, a nie jako węzeł, do którego wchodzą i wychodzą połączenia.

@LukeJL: Jasne, tylko próbuję się trzymać tego co proponuje C4, chmurek tam nie ma :) Podobnie z checkboxami, czy suwakiem LOD

Tak po prawdzie to jakby sie tak czepiać to aktor też nie wali bezposrednio do serwisu pewnie tylko wcześniej jest jeszcze jakaś warstwa kliencka ;p

IMO zależy od contextu w jakim to bedzie umieszczone. W jednym moze byc potrzebne w drugim nie :)

W zasadzie diagram powinien byc ogolny, bo to jakie api sobie w srodku gdzies uderza to nie ma znaczenia i tak dostajemy na wstepie info do jakiego API zapytac i zwortke JSON. nic wiecej nie potrzeba

@chomikowski: Dobra, tylko to jest jeden z 4 poziomów tego diagramu. Na górze jest kontekst, czyli coś takiego:

Dopiero "wklikując" się w system masz diagram kontenerów i tutaj, z tego co rozumiem, powinno być już pokazane nieco "jak" żądanie jest realizowane.