Architektura i wzorce

Architektura oprogramowania to zbiór decyzji, które trudno cofnąć — podział na moduły, sposób komunikacji między nimi, granice odpowiedzialności. Wzorce projektowe są próbą nazwania rozwiązań, które sprawdziły się wcześniej, żeby nie wymyślać ich za każdym razem od nowa.

W tej kategorii zbieramy teksty o stylach architektonicznych, kompromisach między nimi i o tym, kiedy dany wzorzec pomaga, a kiedy dokłada złożoności bez zysku.

Kiedy architektura zaczyna mieć znaczenie?

Wcześniej, niż się wydaje — ale nie od pierwszego dnia. Mały produkt udźwignie niemal każdą strukturę; problem zaczyna się, gdy rośnie zespół i liczba miejsc, które trzeba zmienić przy jednej poprawce. Architektura ma znaczenie dokładnie tam, gdzie decyzji nie da się tanio cofnąć: granice modułów, podział na usługi, wybór sposobu komunikacji, model danych. Resztę — nazwy, foldery, biblioteki — można porządkować w trakcie.

Po co komu wzorce projektowe?

Wzorzec to nazwane rozwiązanie problemu, który wystąpił wystarczająco wiele razy, żeby dorobić się nazwy. Wartość wzorców jest podwójna: dają gotową konstrukcję tam, gdzie problem faktycznie występuje, i wspólny język — „obserwator", „fasada", „repozytorium" mówią zespołowi więcej niż akapit opisu. Koszt pojawia się wtedy, gdy wzorzec stosuje się na zapas: każda warstwa abstrakcji, która niczego nie ukrywa, jest złożonością bez zysku.

Jakie decyzje architektoniczne wracają w każdym projekcie?

Monolit czy usługi — i gdzie przebiegają granice, jeśli usługi. Komunikacja synchroniczna czy zdarzeniowa — i co się dzieje, gdy odbiorca nie odpowiada. Jedna baza czy osobne magazyny — i kto jest źródłem prawdy dla współdzielonych danych. Wreszcie: ile spójności wymusić regułami, a ile zostawić konwencji. Na żadne z tych pytań nie ma odpowiedzi uniwersalnej — jest za to wspólna zasada: decyzję podejmuje się wtedy, gdy jest potrzebna, i zapisuje się, dlaczego zapadła, bo za dwa lata nikt nie będzie pamiętał kontekstu.