Czym jest Architecture Decision Record

Czy zastanawialiście się kiedyś, dlaczego opracowywana aplikacja korzysta z danej technologii? Dlaczego Java, a nie Python? Dlaczego potrzebujesz mikroserwisów lub monolitu? Istnieje mnóstwo pytań, które często przychodzą na myśl programistom. Zazwyczaj mówi się, że takie są zasady zostały ustalone i koniec. Kto je ustalił i dlaczego? Czy Ci co to robili jeszcze tutaj są?

Może istnieć zespół ludzi, którzy podejmują tego typu decyzje. Nazywa się ich zazwyczaj architektami. Byłoby super, gdybyśmy nie musieli się ich za każdym razem pytać o wyjaśnienie, co nimi kierowały przy podejmowaniu danej decyzji. Zawsze, gdy dokonamy ważnego wyboru, który będzie mieć wpływ na architekturę czy pracę innych osób, powinniśmy zostawić po tym jakiś ślad. Dzięki temu, będziemy mogli wyciągać z tych decyzji wnioski, rozumieć okoliczności ich podjęcia i znajdować alternatywne rozwiązania.

Architecture decision record (ADR) to mały dokument, który właśnie to opisuje. Istnieje wiele prostych oraz złożonych szablonów, które można na początku wykorzystać. Każda decyzja jest przechowywana w osobnym pliku ADR z opisem problemu, okoliczności, rozwiązań alternatywnych, wniosków i ostatecznej decyzji.

Taki rekord może być przechowywany w osobnym dokumencie w repozytorium kodów i być przedmiotem code review. Będziemy mogli wtedy zobaczyć, jakie były wyzwania i jak z czasem nasza architektura ewoluowała. Takie podejście zwiększa transparentność.

Oto przykład szablonu Architecture Desicion Record, który został zaproponowany przez Michaela Nygarda:

Szablon ADR autorstwa Michaela NygardaOto szablon dokumentowania decyzji dotyczących architektury - Michael Nygard.W każdym pliku ADR napisz następujące sekcje:
Tytuł

Status
Jaki jest status (zaproponowany, przyjęty, odrzucony, nieaktualny, zastąpiony itp.)

Kontekst
Jaki problem stoi za daną decyzją lub zmianą?

Decyzja
Jaką zmianę proponujemy lub wprowadzamy?

Konsekwencje
Co staje się łatwiejsze lub trudniejsze z powodu takiej zmiany?

Nie trzeba się tego sztywno trzymać. Świetne w Architecture Decision Record jest również to, że możemy dokumentować odrzucone rozwiązania i wyjaśniać wszystkim, dlaczego takie podejście nie byłoby korzystne.

Zobaczmy, jak może właściwie wyglądać ADR. Rozwijamy wiele mikroserwisów za pomocą PHP i chcemy ustandaryzować używane frameworki webowe. Nasz ADR powinien mieć niski narzut i być łatwy do przyjęcia przez obecny zespół programistów.

5. Framework PHP

Data: 2020-03-20

Status 
Zaproponowano

Kontekst
Musimy użyć frameworka webowego, aby przyspieszyć rozwój nowych usług PHP

Rozwiązania
Opcja 1: Lumen
Opcja 2: Slim

Decyzja
Oba frameworki są szeroko stosowane, opracowane przez aktywne społeczności i zapewniają podobną wydajność, ale ponieważ większość programistów miała wcześniej doświadczenie z Laravelem (bardzo podobne do Lumen), Lumen będzie łatwiejszy do przyjęcia.

Konsekwencje
Lumen zostanie wykorzystany w nowych usługach PHP

Stosowanie lightweight Architecture Decision Record jest również zalecaną techniką programistyczną opracowaną przez Technology Radar od ThoughtWorks.

Źródła:

https://www.oreilly.com/library/view/design-it/9781680502923/
https://github.com/joelparkerhenderson/architecture_decision_record
http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions