Dziś przyszedł czas na poruszenie tematu architektury aplikacji typu enterprise. Planuje napisać cykl postów m.in. o różnych wzorcach projektowych wykorzystywanych do budowy kolejnych warstw systemu. Zacznę od totalnych podstaw, które mają na celu wyjaśnienie z czego tak naprawdę powinna się składać solidna aplikacja. Przedstawię również kilka prostych zasad inżynierii oprogramowania mających na celu usprawnienie pisania elastycznego kodu.

Zacznijmy od określenia czym jest aplikacja enterprise. Według niektórych definicji jest to oprogramowanie rozwiązujące problem biznesowy (ERM, CRM itp). Definicja według mnie jest  zbyt  ogólna i niewyjaśniająca znaczenia z punktu technicznego. Dla architekta \ programisty oprogramowanie enterprise powinno być kojarzone z następującymi cechami:

1. Skalowalność – system powinien być przygotowany na wzrost liczby użytkowników zarówno pod względem architektonicznym(rozszerzalność kodu) jak i wydajnościowym(np. load balancing),
2. Bezpieczeństwo,
3. Modularność,
4. Możliwość dostarczania modułów przez różnych dostawców(inna firma piszę CRM a jeszcze inna system sprzedaży),
5. Jawne oddzielenie logiki od spraw technicznych(interfejs nie zna specyfiki rozwiązywanego problemu ani źródła danych),
6. Wysoce skomplikowane systemy – implementowane i wdrążane przez lata,
7. Systemy rozproszone.

Z pewnością do powyższych cech można jeszcze dodać wiele elementów. Uogólniając aplikacjami klasy enterprise są programy solidne, elastyczne i otwarte na wszelkie modyfikacje.

Następne pytanie brzmi, jak zaprojektować taką aplikację? Część odpowiedzi będzie znajdować sie w kolejnych postach. Popatrzmy jednak w tej chwili na wskazany problem bardziej ogólnie. Zdefiniujmy warstwy(części) na które składa się każdy system enterprise. W podejściu Rapid Application Development(RAD), promowanym przez nowoczesne środowiska programistyczne sprawa jest prosta. Pisząc prostą aplikacje np. w Visual Studio tworzymy nowe okno i dodajemy kod obsługi bezpośrednio w pliku źródłowym okna. W poważniejszych aplikacjach niezbędne okazuje się oddzielenie od siebie przynajmniej trzech warstw kodu:

1. Warstwy prezentacji,
2. Warstwy biznesowej,
3. Warstwy dostępu do danych.

Dokładny opis warstw znajdzie się w przyszłych postach – w tej chwili wyjaśnię tylko ogólnikowo. Warstwa prezentacji to wszystko to co widzimy  czyli interfejs użytkownika(GUI). Warstwa biznesowa jest rdzeniem aplikacji i odpowiada za rozwiązywanie problemów dla których została stworzona aplikacja. Czasami rozdziela się warstwę biznesową dodatkowo na warstwę usług aby uniezależnić kwestie technologiczne od implementacji tej warstwy . Warstwa dostępu do danych odpowiada za fizyczny zapis danych do dowolnej bazy danych. Poniżej przedstawiam warstwy wraz z kilkoma wzorcami projektowymi które można wykorzystać:

Spora część wzorców będzie omawiana na bieżąco w przyszłych postach zatem zachęcam do czytania.