To jest artykuł z serii Proces ewolucji architektury.

9 rano, siadasz z ludźmi, którzy chcą, żeby zaprojektować architekturę systemu. Twoja wiedza domenowa = null.

Zaczynają zasypywać cię gradem szczegółów.

10.30 mózg przestaje absorbować informacje. Czujesz się jak po całym dni w obcym kraju, gdzie musiałeś wytężać 100% uwagi, żeby zrozumieć choć trochę co do ciebie mówią. Naturalna reakcja obronna organizmu jest zabawna - chce ci się spać. O, żeby zdrzemnąć się choć na minutkę... Stop!

Zbuduj sobie ogólne overview na sytuację. Określ kontekst środowiskowy systemu, z kim on współpracuje i jakie informacje wymienia z otoczeniem:

  • trzymaj się na dość dużym poziomie ogólności; na tym etapie szczegół to twój wróg, uśpi cię szybciej niż myślisz

  • definiuj: nazwy systemów, odpowiedzialności systemów (jednym zdaniem), nazwy operacji wykonywanych pomiędzy systemami (czego chce jeden od drugiego?), nazwy protokołów (tylko nazwy)

  • unikaj: formatów przesyłanych danych, sposobów nawiązywania połączeń itp; jeszcze nie jest na to czas


Nie wstydź się bazgrać
Celem tych działań jest zrozumienie z czym masz do czynienia, ani brylowanie znajomością UMLa. Na tym etapie diagram komponentów wcale nie jest bardziej profesjonalny niż prostokąty nabazgrane na kartce. Diagram to tylko umowa co do formatu rysunków, jeśli kredki odpowiadają ci bardziej dlaczego ich nie używać?

.