C4 - Zwinne podejście do odkrywania i dokumentowania architektury

W jaki sposób dokumentować architekturę systemu - z jednej strony tak, aby zawrzeć wszystkie potrzebne informacje, z drugiej zaś, aby nie przeładować dokumentacji szczegółami, które czynią ją bezużyteczną?

Pracując z zespołami podczas warsztatów architektonicznych rozpoczynam zwykle od "zadania na rozgrzewkę", którego treść jest krótka: "wyobraźcie sobie, że od jutra dołączam do Waszego teamu; narysujcie proszę architekturę systemu, nad którym aktualnie pracujecie aby szybko i efektywnie wprowadzić mnie w kontekst oraz abym wiedział  gdzie 'włożyć ręce'".

Jak widać treść nie doprecyzowuje o jaki rodzaj architektury chodzi (aplikacyjna, systemowa, wdrożeniowa, etc) oraz w jaki sposób należy to zrobić - po prostu "tak jak robicie to aktualnie w projekcie", a jeżeli tego typu aktywności nie są podejmowane, "intuicyjnie, jak byś to zrobił/zrobiła".


/*************************
Wiem, że zewnętrzny doradca, który chce 'włożyć ręce' w projekt to niespotykany okaz. Większość z nich to osobniki typu krokodyl - małe rączki, duża gęba (czytaj: nic nie robi, dużo gada).

**************************/

Typowe problemy, jakie pojawiają się podczas prób wizualizowania architektury oraz jeden ze sposobów radzenia sobie z takim krytycznym zadaniem jakim jest komunikowanie swoich pomysłów i strategicznych decyzji opisałem w najnowszym numerze programistamag.

Artykuł C4 - Zwinne podejście do odkrywania i dokumentowania architektury jak zwykle do pobrania (jak zwykle free) tutaj: Niezbędnik początkującego projektanta i architekta (zachęcam oczywiście do odwiedzenia empiku lub zakupu wersji elektrycznej całego numeru).


//===================================================

Zainteresowanych zgłębieniem tematu odsyłam do książki Software Architecture for Developers oraz artykułu, który kilka dni temu ukazał się na infoq.

Ze doświadczenia swego oraz zespołów, z którymi pracuję mogę podzielić się jednym rozszerzeniem do C4:  mianowicie w większych systemach Komponenty warto grupować w Moduły (czyli: Context Containers Modules Components Classes). Wewnątrz modułu komponenty "widzą" się wzajemnie, natomiast poza modułem jest widoczny jedynie podzbiór API np. w formie Fasady lub emitowanych zdarzeń (część zdarzeń, które pojawiają się wewnątrz modułu).