TECH MONDAY: Model C4 w Dynamics 365 i Power Platform – cztery poziomy architektury

Dokumentacja architektury powinna pokazywać zarówno miejsce systemu w organizacji, jak i szczegóły jego budowy. Model C4 porządkuje te informacje za pomocą czterech poziomów abstrakcji.

W projektach Dynamics 365 Customer Engagement i Power Platform można w ten sposób opisać systemy oraz integracje, rozwiązania Dataverse, aplikacje Power Apps, mikroserwisy, niestandardowe API, przepływy i kod.

Cztery perspektywy modelu C4

Opracowany przez Simona Browna model przedstawia architekturę hierarchicznie – od ogólnego otoczenia systemu po technologie wykorzystywane w jego kodzie.

Nazwa C4 odnosi się do czterech poziomów:

• C1 – kontekst,
• C2 – kontenery,
• C3 – komponenty,
• C4 – kod.

Każdy kolejny poziom odpowiada na inne pytania i przedstawia rozwiązanie z większą szczegółowością. Ułatwia to rozmowę o architekturze zarówno z osobami technicznymi, jak i odbiorcami bez wiedzy technicznej.

Zastosowanie C4 w projektach Dynamics 365 i Power Platform

Wdrożenia rozwiązań Microsoft często obejmują wiele aplikacji, usług i integracji. Model C4 pozwala przyporządkować te elementy do odpowiedniego poziomu dokumentacji.

Ogólny kontekst pokazuje rolę biznesową systemu i jego otoczenie. Kolejne warstwy przedstawiają jednostki tworzące rozwiązanie, odpowiedzialne za konkretne funkcje komponenty oraz wykorzystywany kod.

Takie odwzorowanie pozwala zastosować model również do projektów wykorzystujących narzędzia low-code i no-code.

C1 – kontekst systemu i jego integracje

Na najwyższym poziomie przedstawiane są relacje między rozwiązaniem a innymi systemami działającymi w organizacji.

Warstwa C1 może pokazywać ogólną architekturę logiczną Dynamics 365 Customer Engagement, jego rolę biznesową oraz połączenia z:

• systemami ERP,
• platformami do zarządzania dokumentami,
• wewnętrznymi i zewnętrznymi API,
• pozostałymi systemami wykorzystywanymi w organizacji.

Ten poziom pozwala zrozumieć, gdzie rozwiązanie znajduje się w całym środowisku biznesowym.

C2 – jednostki przechowujące logikę i dane

W nomenklaturze C4 kontener oznacza niezależnie uruchamianą lub wdrażaną jednostkę, która przechowuje logikę biznesową albo dane.

Nie jest to kontener Docker, moduł kodu ani biblioteka. W środowisku Power Platform taką rolę mogą pełnić:

• rozwiązania Dataverse,
• aplikacje Power Apps,
• mikroserwisy działające w Azure, które obsługują integracje lub główną logikę systemu.

Warstwa C2 przedstawia więc główne części rozwiązania i podział odpowiedzialności między nimi.

C3 – komponenty realizujące określone funkcje

Na tym poziomie dokumentowane są elementy odpowiadające za konkretną funkcjonalność i udostępniane jako usługa, endpoint API albo interfejs.

W ekosystemie Power Platform do komponentów można zaliczyć:

• niestandardowe API,
• plug-iny,
• biblioteki JavaScript,
• kontrolki PCF.

Po uwzględnieniu narzędzi low-code i no-code mogą to być również:

• przepływy,
• strony niestandardowe,
• komponenty canvas.

Pozwala to objąć jednym sposobem dokumentowania zarówno kod, jak i elementy konfigurowane za pomocą narzędzi platformy.

C4 – technologie wykorzystywane w kodzie

Najbardziej szczegółowa warstwa może przedstawiać kod uruchamiany w systemie operacyjnym, usłudze chmurowej albo na platformie SaaS.

W rozwiązaniach Power Platform mogą być wykorzystywane:

• C#,
• Visual Basic .NET,
• TypeScript lub JavaScript,
• Power Fx.

Do ich opisania można zastosować wybraną notację, na przykład UML, schematy blokowe lub grafy zależności.

Praktyczne odwzorowanie architektury rozwiązania

Dla projektu Dynamics 365 lub Power Platform podział może wyglądać następująco:

• kontekst – rola biznesowa, użytkownicy, systemy i integracje,
• kontenery – rozwiązania Dataverse, aplikacje Power Apps i mikroserwisy Azure,
• komponenty – API, plug-iny, biblioteki, kontrolki, przepływy i komponenty canvas,
• kod – C#, Visual Basic .NET, TypeScript, JavaScript i Power Fx.

Tak uporządkowana dokumentacja pozwala omawiać architekturę na poziomie dopasowanym do odbiorcy, bez ograniczania opisu wyłącznie do tradycyjnie tworzonego kodu.