Pēc klasikas jebkura sistēmai var izdalīt vismaz trīs slāņus. However vairāk vai mazāk ir iespējams izdalīt sekojošus apgabalus jeb slāņus:
- Prezentācijas slānis.
- Biznesa loģikas slānis.
- Datu piekļuves slānis.
- Platforma jeb Cross-Cutting.
Īpaši ar mākslinieciskām dotībām neesmu apveltīts, bet šāda bilde man pastāvīgi redzama pie sienas :)
Prezentācijas slānī parasti atrodas:
- Web interfeiss. Lietotāja interfeisa tīmekļa aplikācijas izskatā. Šis punkts protams ļoti atkarīgs no sistēmas un produkta, bet jebkurā gadījumā vairums modernajām sistēmām ir vismaz viens lietotāja interfeiss balstīts uz tīmekļa tehnoloģijām.
- Desktop interfeiss. Iespējams, ka eksistē arī kāds lietotāja interfeiss, kas ir balstīts uz Windows Formām vai WPF.
- Publiskie servisi (web servisi). Pārsvarā eksistē sistēmā arī kaut kādi servisi, kas tiek izmantoti no ārpuses. Piemēram, dažāda veida servisu piegāde ārējām sistēmām jeb ārējiem biznesa loģikas patērētājiem.
- Background (fona) servisi. Fonā parasti notiek arī kaut kādas aktivitātes, kur nav nepieciešams cilvēka pirksta pieskāriens. Ir dažāda veida servisi jeb procesi, kas notiek vai nu regulāri vai arī reaktīvi reaģējot uz kādu no notikumiem, kas notiek sistēmā. Notikumi parasti notiek biznesa objekta modelī (piemēram, apdrošināšanas polise beidzas – fona process ir atbildīgs par atbilstošā statusa uzstādīšanu).
- Administrācijas vide. Caur kaut kādu UI sistēmas administratoriem jādod iespēju arī administrēt to biznesa sistēma un pārējos dažādos artefaktus, kas figurē sistēmā (piemēram, lietotājus vai klasifikatorus, etc.).
- Kaut kas vēl custom specifisks konkrētajai sistēmai vai produktam. Dažāda veida tooļi, scripti vai kādi helper apgabali, kas bagātina un papildina kopējo sistēmas funkcionalitāti.
Par biznesa loģiku nav daudz ko stāstīt. Tur parasti atrodas biznesa loģika, dažādi “manageri” (kaut dzīvē bieži esmu redzējis, ka cilvēki ražo biznesa slānī tieši menedžerus, kas prot daudz ko un atbild par daudz ko, tomēr man uzskats ir ka, ka kopsummā ir sistēma jākonstruē tā, ka ir strikti nodalītas atbildības, katra klase atbild par kādu konkrētu biznesa procesa daļu, operāciju, funkcionalitāti vai atbildību), pārvaldnieki, biznesa procesu draiveri, servisu fasādes un kas vēl ne cits.
Savukārt ar datu piekļuves slāni parasti ir interesantas diskusijas. Un diskusijas parasti ir par to, vai speciāli ir nepieciešams izdalīt datu piekļuves slāni kā atsevišķu bibliotēku vai assembliju. Cik no pieredzes es varu spriest, izdalīt atsevišķu datu piekļuves slāni ir izdevīgi un nepieciešams gadījumos, kad sistēmai vai produktam ir jāatbalsta vairākas datu bāzes vadības sistēmas. Un izdevīgi to ir veidot tā, ka pārējā sistēmas daļa ir neatkarīga no datu bāzes vadības sistēmas izvēles un viss notiek noteiktā abstrakcijas līmenī.
Parasti, pielietojot modernās datu piekļuves tehnoloģijas ērti un organiski sanāk nedaudz sapludināt biznesa slāni ar datu piekļuves slāni un kontraktiem no platformas jeb cross-cutting slāņa, tādā veidā izdalot jaunu slāni – Data Contracts, kurš tāpat kā Cross-Cutting ir pieejams visiem slāņiem un komponentēm. Vienības no Data Contracts slāņa parasti kalpo kā saziņas līdzeklis un interfeiss komunikācijās starp dažādiem slāņiem un sistēmas komponentēm.
Platformā cilvēki parasti saliek visu pārējo, kas ir palicis pāri nesadalīts starp iepriekšējiem slāņiem. Tas gan ir stipri atkarīgs no sistēmas vai produkta, bet vairums situācijās jebkurā no sistēmām var izdalīt sekojošas sadaļas jeb komponentes, kas atrodas platformas slānī:
- Logging. Žurnalizēšana un viss ar to saistītais (gan tehniskais žurnāls, gan arī biznesa), API, etc.
- Caching. Kešatmiņas tehnoloģijas un pieejas izvēle arī brīžiem var radīt nelielas galvas sāpēs arhitektiem un inženieriem.
- Configuration. Noteikti sistēmās ir kāda sadaļa, kurā uzglabājas dažāda veida konfigurācijas parametri un uzstādījumi. Brīžiem arī interesants jautājums, kā to visu saglabāt un padarīt pieejamu dažādiem slāņiem un komponentēm, kā rīkoties situācijās, kad mainās konfigurācijas uzstādījuma vērtība, vai vienmēr pārlasīt vērtību pie katras tās pieprasīšanas vai tomēr izvēlēties kādu no kešatmiņas risinājumiem? Arī šie jautājumi mēdz nomākt arhitektus.
- Error Handling. Reti kura sistēma ir uzrakstīta bez nevienas kļūdas. Pareizi tā noķert un apstrādāt ir šī apakšmoduļa uzdevums.
- Authentication un Authorization. Noteikti sistēmā būs nepieciešama dažāda veida drošības risinājumi. Diezgan bieži jaunieši jauc vietām šīs divas smalkās lietas.
- Monitoring. Šī apakšmoduļa uzdevums ir sekot sistēmas veselības stāvoklim, aplūkojot un ziņojot par dažādiem problēmapgabaliem vai situācijām. Parasti šīs lietas tiek atstātas novārtā, bet patiesībā, ja jums iznāk strādāt pie kāda produkta, mēģiniet sev iestāstīt, ka jebkurai sistēmai ir jānodrošina kaut kāda veida diagnostikas iespējas un jālaiž ražošanā ar iestrādātiem speciāliem diagnostikas portiem vai interfeisiem, atvērtām iespējām noskaidrot, kas notiek sistēmā un vai nevajadzētu pievērst kāda sistēmadministratora uzmanību.
- Localization. Parasti mūsdienās attālumam vairs nav nozīmes un nereti ir situācijas, kad indieši raksta kodu amerikāņiem, vai norvēģi ievieš savu sistēmu Zviedrijā, etc. Tā kā ar vien biežāk nākas domāt par lokalizāciju un sistēmas daudzvalodību. Šīs problēmas risināšanai tiek veidoti moduļi, kas ietilpst šajā komponentē.
- Validation. Datu kontraktu satura pareizīguma pārbaude un verifikācija notiek parasti šajā komponentē. Tas, protams, ir stipri atkarīgs no sistēmas un produkta, bet parasti vairums sistēmas eksistē kāda veida datu validācija pirms tie nokļūst datu glabātuvē (parasti datu bāzē).
Šīs ir lietas un aspekti, kurus esmu saskatījis vairākās sistēmās, kurās man bijis tas gods piedalīties un palīdzēt cilvēkiem tikt galā ar uzdevumiem (parasti tos sauc par challanges :)).
Ja nu kādam sanāk darboties pie kādas sistēmas vai arī, ja kāds palūdz jums uzzīmēt kādu smuku bildi, kurai pēc biznesa īpašnieku domām būtu jāapraksta un uzskatāmi jārunā par kādas konkrētas sistēmas arhitektūru, tad iespējams, ka varētu noderēt šī layer diagramma, kas tika veidota pārzīmējot diagrammu, kas redzama nedaudz augstāk.
Kā jau mēs zinām, slāņu diagrammu var arī validēt un pārbaudīt pret reālo situāciju, kas ir risinājumā. Tā kā atliek tikai salikt pareizos projektus pareizajos slāņos un viens solis tuvāk nefiltrētajai gaišajai nākotnei ir sperts! :)
Nākamreiz mēģināsim ieskicēt, kāds ir modernais tehnoloģiju stack, kuras var pielietot šādas arhitektūras sistēmās.
Cerams, ka noderēs!