Clean Architecture – rewolucja czy ewolucja, a może tylko nowa nazwa na coś, co już od dawna było wiadomo? Jak to podejście ma się do architektury opartej o mikroserwisy czy Domain-Driven Design? Czy da się zastosować w systemach legacy? A może Twoje podejście do tworzenia oprogramowania zmieni się diametralnie? Jakie problemy rozwiążesz a jakie sobie stworzysz? Jeśli chcesz przyjrzeć się Clean Architecture z perspektywy pragmatyka, koniecznie musisz pojawić się na tej prelekcji.
42. www.bnsit.pl
# Jak to się ma do UC?
# Duża złożoność, szczególnie przy purystycznej
implementacji
• Duża ilość interfejsów na granicach między warstwami
# Osobne modele dla dziedziny, repository, widoku,
interactora Czy współdzielić modele Repository i
Enpty?
• Purystycznie – konfiguracja zewnętrzna (XML, fluent api)
• Akceptujemy niektóre adnotacje (np. w Java @Inject,
ORM)
• Dwie wersje – czysta i z adnotacjami „nadpisana”
# Dependency Inversion wprowadza niebezpośredniość
komunikacji (zdegenerowany obserwator)
Wady
Zwiększamy efektywność zespołów projektowych 42
43. www.bnsit.pl
# Złożone dziedziny – w połączeniu z DDD
# Krytyczne systemy/aplikacje
# Zespoły o wysokich kompetencjach
# Wielu klientów
# Dla długotrwałych projektów
• Dla kilkutygodniowych lub CRUDowych to będzie
killer
• Chyba że chcesz potrenować
# Raczej ewolucja w stronę Clean Architecture
• Clean Architecture nie jest KISS
Kiedy używać?
Zwiększamy efektywność zespołów projektowych 43