Cześć :) kolejny artykuł o dependency injection, teraz o kontenerach po dłuższym czasie ze względu na ilość zajęć :) wszelkie uwagi, rady jak zwykle mile widziane :)

Czy mikroserwisy to Bounded Contexty? Czy modularyzacja na poziomie architektury systemowej powinna wpływać na sposób wdrożenia? Co tak właściwie chcemy osiągnąć wprowadzając podziały na różnych poziomach architektury?

Opis czym zajmuje się architekt IT w firmie.

Architektura nie musi być kosztowna, trzeba tylko podejść do jej tworzenia w rozsądny sposób. Istotne jest, żeby nie popaść w over-engineering z jednej strony i kompletny chaos z drugiej. Na szczęście są zasady i narzędzia, które mogą nam w tym istotnie pomóc.

Na poziomie aplikacji architektura powinna wspierać modelowanie domeny czyli serca całego systemu. Czym powinna się charakteryzować architektura, żeby wspierać podejście Domain First? Czy tradycyjne warstwy są dobrą odpowiedzią na te potrzeby?

Jak podejść do projektowania architektury systemu ? Co trzeba określić już na start, a co może poczekać ? Od czego mogą zależeć wybory architektoniczne i kiedy jest najlepszy moment na ich podjęcie ? Pytania te nie mają niestety jednej prostej odpowiedzi. Przyjęte podejście ma jednak niezwykle istotny wpływ na powstający system.

Kiedy możemy powiedzieć, że architektura naszego systemu jest dobra ? Czy da się znaleźć rozwiązanie, które będzie się dobrze sprawdzać w wielu systemach przez długi czas ? Dobre określenie tego czego się szuka jest kluczowe dla sukcesu poszukiwań. Dlatego warto zastanowić czego oczekujemy od architektury naszych systemów i jakich kryteriów użyć, żeby określić czy jest ona faktycznie dobra.

Domain Model validation in context of Domain Driven Design

Writing your code for better scaling. Quick summary inspired by Damian Edwards and David Fowler.

Kontynujemy dział o dependency innjection, w tym artykule rektoryzujemy kod z poprzedniej części, który jeszcze będzie później dostosowywany do dependency injection.