Pozwolę sobie przytoczyć kilka dobrych praktyk związanych z architekturą.
Struktura poszczególnych modułów powinna być na tyle prosta, aby można ją było w pełni zrozumieć.
2. Moduły powinny być luźno ze sobą powiązane, tzn. powinna być możliwa zmiana implementacji jednego modułu, bez znajomości implementacji pozostałych modułów i bez wpływania na ich zachowanie.
3. Łatwość wprowadzania zmian w projekcie powinna pozostawać w rozsądnej relacji do prawdopodobieństwa wymaganych zmian;
4. Powinno być możliwe wprowadzanie prawdopodobnych zmian bez zmieniania interfejsu jakiegokolwiek modułu;
5. Powinno być możliwe wprowadzanie poważnych zmian oprogramowania w postaci zbioru niezależnych od siebie zmian pojedynczych modułów (tzn. z wyjątkiem zmian interfejsów, programiści zmieniający poszczególne moduły nie muszą się komunikować).
6. Jeśli interfejsy modułów nie są zmieniane, powinno być możliwe uruchamianie i testowanie dowolnej kombinacji starych i nowych wersji modułów.
7. Dokumentacja struktury dekompozycji jest czasami nazywana przewodnikiem po modułach.
8. Podane są w niej zobowiązania poszczególnych modułów przez określenie decyzji projektowych, które mają być w nich obudowywane. Ma ona służyć zapobieżeniu powielaniu i lukom, osiągnięciu rozdzielenia zagadnień i – przede wszystkim – być pomocą dla osób odpowiedzialnych za pielęgnację przy wyszukiwaniu modułów wskazanych w raporcie problemowym lub wniosku zmiany.
9. Powinno być możliwe wprowadzanie poważnych zmian oprogramowania w postaci zbioru niezależnych od siebie zmian pojedynczych modułów (tzn. z wyjątkiem zmian interfejsów, programiści zmieniający poszczególne moduły nie muszą się komunikować).
10. Jeśli interfejsy modułów nie są zmieniane, powinno być możliwe uruchamianie i testowanie dowolnej kombinacji starych i nowych wersji modułów.
11. Dokumentacja struktury dekompozycji jest czasami nazywana przewodnikiem po modułach.
12. Podane są w niej zobowiązania poszczególnych modułów przez określenie decyzji projektowych, które mają być w nich obudowywane. Ma ona służyć zapobieżeniu powielaniu i lukom, osiągnięciu rozdzielenia zagadnień i – przede wszystkim – być pomocą dla osób odpowiedzialnych za pielęgnację przy wyszukiwaniu modułów wskazanych w raporcie problemowym lub wniosku zmiany.
13. Architektura powinna być tworem pojedynczego architekta lub niewielkiego zespołu architektów z ustalonym przywódcą.
14. Architekt (lub zespół architektów) powinien dysponować wymaganiami funkcjonalnymi wobec systemu, a także wyraźnie określonym wykazem oczekiwanych od systemu atrybutów jakościowych (takich jak bezpieczeństwo lub modyfikowalność) z przypisanymi priorytetami.
15. Architektura powinna być dobrze udokumentowana, z uwzględnieniem co najmniej jednej perspektywy statycznej i jednej, przy użyciu uprzednio uzgodnionej notacji, którą wszyscy udziałowcy zrozumieją przy minimum wysiłku.
16. Architektura powinna być rozesłana do wszystkich udziałowców systemu, którzy powinni być czynnie zaangażowani w jej recenzowanie – weryfikację.
17. Architektura powinna być przeanalizowana pod kątem stosownych miar jakościowych (takich jak maksymalna przepustowość) oraz formalnie oceniona pod kątem atrybutów jakościowych, zanim będzie za późno, aby wprowadzać do niej zmiany.
18. Architektura powinna nadawać się do implementacji przyrostowej przez stworzenie systemu „szkieletowego”, w którym byłyby zbadane ścieżki komunikacyjne, lecz który początkowo miałby funkcjonalność ograniczoną do minimum. System taki może następnie posłużyć do przyrostowego rozwijania właściwego systemu, do ułatwiania scalania i testowania.
