Cześć

Ciężko znaleźć materiały odnośnie projektowania aplikacji kilkuwarstwowych w springu. Chciałbym podzielić sobie mój projekt na kilka modułów, tak aby w przyszłości można było w łatwy sposób "postawić", każdy moduł na kilku maszynach. W sieci jest dużo grafów, rysunków, ale nic w praktyce.

Moje założenia.

1. Sesja użytkownika z serwisem musi być w warstwie biznesowej. Tutaj pojawia się pierwsze pytanie, zastanawiałem się nad użyciem CAS. I zintegrować go ze spring security, czyli single sign on. Moje pytanie jest następujące jak replikować sesje na kilka serwerów w warstwie biznesowej ?? Są jakieś przykłady jak to zrobić przy użyciu spring security ?? Moim zdaniem najlepszym wyjściem byłoby użyć szybkiej bazy danych typu key/value np. redis i tam przetrzymywać info odnośnie sesji danego użytkownika??

2. Wykorzystujemy usługi REST i to one łączą się z naszą aplikacją.

3. Oprzeć wszystko na projektowaniu zgodnym z DDD.

Podzieliłem sobie aplikacje na następujące moduły.

Presentation:

1. core - web : moduł kliencki. Statyczne pliki web (css, js, html, angularjs itp)
2. admin - web : to samo tylko tzw. konsola administracyjna dostępna w intranecie.
3. core -android : aplikacja na androida
   Application:
4. core - rest: moduł obsługujący usługi rest dla głównej strony oraz na aplikacje mobilne. Przechowuje tylko usługi rest.
5. admin - rest : to samo tylko dla modułu administracyjnego.
   Domain:
6. core - domain : cała logika biznesowa aplikacji, encje, repository, domena itd. Serce całego systemu.
   Integration:
7. Serwery mongodb oraz psql.

Tutaj pojawiają się moje pytania :) Czy podział aplikacji na powyższe moduły ma sens ?? Czym połączyć core -rest i admin -rest z modułem core - domain (myślałem na użyciu spring integration i bramki 'gateway') ?? W jaki sposób i czy w ogóle spring security radzi sobie z sesją w logice biznesowej (Spring security domyślnie działa w oparciu o ciasteczka, czyli u mnie to by było w warstwie core - rest i admin- rest, natomiast ja bym chcial aby spring security działał w warstwie biznesowej core - domain) ?

Nie mam jeszcze :) takiego doświadczenia jeśli chodzi o projektowanie systemów działających w środowisku klastrowym. Z góry dziękuję za wszystkie uwagi i podpowiedzi.

Przypóśćmy ze nazwa projektu to rdp

1. rdp.ui- web : moduł kliencki. Statyczne pliki web (css, js, html, angularjs itp)

2. rdp.admin.ui- web : to samo tylko tzw. konsola administracyjna dostępna w intranecie.

3. rdp.mobile.ui : aplikacja na androida

4. rdp.core: cała logika biznesowa aplikacji, encje, repository, domena itd. Serce całego systemu.
   4.1) rdp.core.remote: rest do logiki biznesowe

5. drp.ds

Bez tego - web co mi sie nie ucieło

Po pierwsze zastanów się jakie wymagania mogą mieć w wpływ na podział komponentów ?
Bo nie ma ich sensu dzielić dla samej poprawności politycznej. Podział logiczny kodu źródłowego głównie uzyskujesz poprzez pakiety (package), a nie jary. Na jary/wary dzielisz głównie dla potrzeb wdrożeniowych.

To co napisałeś jako ogólny podział logiczny jest jak najbardziej ok. Natomiast pytanie czy warto dzielić to również na jary/wary:

• core/admin web/rest - czy przewidujesz że kiedykolwiek będzie to wdrażane oddzielnie ? z np. pominięciem jednego z komponentów ? lub wręcz podmienieniem komponentu na inny ? czy oby na pewno będą musiały być kiedykolwiek wdrażane na oddzielnych serwerach ? PS. skalowalność możesz osiągnąć bez podziału
• core domain - czy planujesz to wykorzystać do jakieś innej wersji systemu bez core/admin web/rest ? czy aplikacje kliencie web i android łączą się zawsze z serwerem poprzez REST czy to grube klienty co odpalają core domain ?

walec51 napisał(a):

Po pierwsze zastanów się jakie wymagania mogą mieć w wpływ na podział komponentów ?
Bo nie ma ich sensu dzielić dla samej poprawności politycznej. Podział logiczny kodu źródłowego głównie uzyskujesz poprzez pakiety (package), a nie jary. Na jary/wary dzielisz głównie dla potrzeb wdrożeniowych.

To co napisałeś jako ogólny podział logiczny jest jak najbardziej ok. Natomiast pytanie czy warto dzielić to również na jary/wary:

• core/admin web/rest - czy przewidujesz że kiedykolwiek będzie to wdrażane oddzielnie ? z np. pominięciem jednego z komponentów ? lub wręcz podmienieniem komponentu na inny ? czy oby na pewno będą musiały być kiedykolwiek wdrażane na oddzielnych serwerach ? PS. skalowalność możesz osiągnąć bez podziału
• core domain - czy planujesz to wykorzystać do jakieś innej wersji systemu bez core/admin web/rest ? czy aplikacje kliencie web i android łączą się zawsze z serwerem poprzez REST czy to grube klienty co odpalają core domain ?

Dzięki za odpowiedź
Cały czas się uczę jeśli chodzi o sprawy związane z architekturą, dlatego każde sugestie są dla mnie na wage złota.

Ogólnie web/android to być grube klienty, 'rozmawiają' z serwerem tylko poprzez REST. Domyślnie logika domenowa ma być oddzielona od prezentacji.

Pytanie po co dzielić na jary / wary. Tak sobie myślę, że z trzech głównych powodów:

Przecież przykładowo statyczny kontent (html, css , js itd), są tylko na potrzeby web. Po co obciążać serwer pewną logiką biznesową i jednocześnie na tej maszynie trzymać statyczny kontent.

Można łatwiej zarządzać projektem. Np. programiści frontend nie potrzebują zbytnio wiedzieć co jest z tyłu. Ich powinno interesować jak to przedstawić, z tej perspektywy api jakie udostępnia aplikacja poprzez rest.

#łatwiej pisać kod , utrzymać projekt.

Podział core/admin daje duże możliwości. Przykładowo moduł admin ma być napisany z wykorzystaniem OSGI, dzięki temu projekt tem będzie mógł być łatwo adoptowany do innych projektów. Część funkcjonalności wspólnej będzie taka sama, reszta na zasadzie wtyczek dopinana w zależności od potrzeb.

Jak by nie patrzeć jestem tylko programistą javy. Zazwyczaj siedzę i klepę kod starając się, aby był jak najlepiej napisany. Dlatego nie mam doświadczenia, jeśli chodzi o część praktyczną.
Całą moją wiedzę opieram na tym co gdzieś doczytałem. Wydaje mi się jednak, że rest jako tako jest najlepiej skalowalny. Jak by nie patrzyć cała sieć www działa jako jedna wiekla usługa rest.

Co do 1:

A co będzie generowało kod HTML ?
Jeżeli nie potrzebujesz SEO to może nie jest to problem. Ale jeżeli SEO potrzebujesz to gruby kod będzie do wykonania na serwerze, więc nie tylko JS.

Co do 2:

No raczej bez znajomości modelu danych i logiki działania aplikacji GUI nie napiszą. Implementacji w szczegółach nie muszą znać. Tylko nadal nie widzę uzasadnienia aby to wielce dzielić. A już na pewno nie na oddzielne serwery bo wtedy nie ma przebacz: wszystkie usługi muszą mieć wydzielone interfejsy, jakąś technologie to remotingu trzeba wrzucić + dodajesz obciążenie w postaci serializacji danych między serwerami.

PS. Co do OSGi to chyba nie wiesz z czym to się je. To jest dosyć duża kobyła, a mimo tego nie jest złotym środkiem co ci automagicznie załatwi modułowość w systemie. Nie ma takiej technologii co Ci modułowość załatwi za free - jak zaczniesz w tym babrać to zrozumiesz czemu. Znacznie tańsze jest podejście warstwowe (w sensie horyzontalnym, nie wertykalnym typu GUI<->model domenowy<->repozytoria danych) - opiera się staroświeskich jarach i assembly statycznej - w przeciwieństwie do dynamicznego modelu OSGi.

Powiem Ci tak, projektanci systemów dzielą się na trzy grupy:

1. Co robią na odczep - jadą po linii najmniejszego oporu i nie patrząc na wymagania zawsze składają system tak jak się tego raz nauczyli
2. Co kochają złożoność - naczytali się więcej niż narobili w życiu (w tym też sporo marketingowych bzdur) i chcą zastosować w projekcie wszystko czego się tym sposobem dowiedzieli
3. Co wiedzą że gorsze jest czasem lepsze - czują ile różne wzorce i technologie dodają złożoności do projektu, nie stosują armat jeżeli do uwalenia jest wróbel, nie śnią że wróbel może w przyszłości przeistoczyć się geparda

Tylko Ci z grupy 3 oddają systemy w terminie, których koszt rozwoju rośnie w normalnym tempie.

Dobrze że próbujesz projektem systemu wybiec trochę w przód - nie dobrze że próbujesz lekkomyślnie do niego władować wszystkie wzorce/techniki o których słyszałeś.

PPS. Co do skalowalności - nie ma tak łatwo. Do aplikacji które ja nazywam "content driven", czyli CMSy i portale typu Allegro - REST, web i skalowanie horyzontalne działa pięknie. Ale spróbuj to zastosować do dużych systemów typu WMS albo MES gdzie danych jest nie wiele (dziesiątki/setki gigabajtów) ale pojedyncze transakcje co chwila niemal mielą CAŁĄ bazę danych (planowanie i sterowanie operacjami logistycznymi, trasami wózków, rozkładem zasobów w magazynie, ...) - to padniesz.

Myślę, że fajnie to podsumowałeś (sprwadziłeś na ziemię :))