Jak podejść do architektury projektu

architektura Komentarze

Jak podejść do architektury projektu

W sieci można znaleźć mnóstwo przykładów w jaki sposób projektować aplikację. Tyle samo, albo i więcej, jest pytań programistów. Jedni szukają wiedzy, bo dopiero wchodzą w ten fascynujący świat. Inni szukają tylko potwierdzenia czy własne pomysły się sprawdzą.

Sam nie raz szukałem odpowiedzi na pytanie czy moja koncepcja jest już przez kogoś gdzieś użyta. Jeśli znalazłem rozwiązanie, które było podobnie zrealizowane jak moje to czułem się pewniejszy, że nie tylko ja na to wpadłem. Znaczy się nie jestem taki w ciemię bity i co najważniejsze – skoro ktoś w podobny sposób rozwiązał problem to może oznaczać to, że nie stanę za chwilę przed ścianą nie do przejścia i w perspektywie najbliższego czasu nie będę musiał przerabiać połowy aplikacji.

Wiele pytań, które są publikowane na znanym wszystkim stackoverflow to pytania techniczne. Czy stosować Repository Pattern? Czy można wstrzykiwać repozytoria do obiektów biznesowych? Czy można wstrzykiwać serwisy do obiektów biznesowych? Czy ValueObject zawsze musi być niezmienny? I tak w nieskończoność.

Sam nie raz pytałem, bo miałem nadzieję, że prawidłowa odpowiedź doprowadzi mnie do tego, że problemy odpłyną w siną dal i będę miał pięknie działającą aplikację bez żadnych wad, z pięknym, wręcz referencyjnym kodem. Co z tego, że ten piękny kod w oczach klienta nie będzie miał żadnego znaczenia jeśli aplikacja nie będzie spełniać założeń biznesowych. Satysfakcja jest. :)

Są miejsca w sieci, gdzie można by skierować większość pytających, aby obejrzeli kilka porządnych wykładów na temat architektury i to powinno rozwiązać problem. Dlaczego? Jest kilka maksym, które przy projektowaniu aplikacji są stałe i niezmienne. Reszta to detal. Aplikacja ma działać i realizować założenia projektowe. Sposób implementacji tak naprawdę jest sprawą drugorzędną.

Jakieś konkrety?

Pisząć projekty (w szczególności odnoszę się tu do własnego podwórka, czyli do aplikacji internetowych) można dojść do kilku wniosków i podzielić architekturę na kilka warstw:

Powyższy słowno-muzyczny opis architektury aplikacji zapewne jest Wam wielu znany.

Oczywiście lepiej jest jeśli powyższe założenia będą w jakiś sposób sformalizowane. Porządek w kodzie się przyda. W związku z czym w kolejnych wpisach postaram się przejść (w miarę szczegółowo) przez każdą z warstw i pokazać w jaki sposób możemy sobie ułatwić życie i stworzyć aplikację, która nie będzie się nam śniła w najgorszych koszmarach.

Komentarze