Arhitectura orientata spre functii pentru aplicatii web

Caracteristica este un concept foarte natural pentru ca oamenii sa inteleaga un sistem. Este, de asemenea, utilizat pentru a descrie cerintele utilizatorilor pentru dezvoltarea de software. Dar atunci cand o caracteristica vine de partea programatorilor, de obicei este convertita imediat in artefacte tehnice, cum ar fi componente, actiuni, modele etc. Aceasta conventie adauga dificultatea pentru noii veniti sau dezvoltatorii insisi serval saptamani mai tarziu pentru a intelege sistemul.

Deci, daca organizam un proiect web in functie de caracteristici si nu de categorii de tehnici (cum ar fi componente, actiuni, modele), acesta ne va ajuta sa gestionam intotdeauna proiectul sub control atunci cand proiectul creste, deoarece construim sistemul cu unitati mai mari.

Aceasta arhitectura este, de asemenea, conceptul cheie al Rekit, un set de instrumente pentru construirea de aplicatii web cu React, Redux si React router.)

https://github.com/supnate/rekit

Spre deosebire de sistemul backend, aplicatia web frontend este interfata directa pentru ca utilizatorul sa inteleaga capacitatile unei aplicatii.

Array

Deci, este mai potrivit sa fie organizat dupa functii.

Ce este o caracteristica?

La inceput, sa definim ce inseamna o caracteristica:

O caracteristica este o anumita capacitate a unui sistem.

Aceasta este o caracteristica care adauga intotdeauna unele functionalitati unui sistem. De exemplu, pentru un sistem de gestionare a continutului, un nou tip de continut acceptat este o caracteristica, pentru un IDE capacitatea de a rula teste este o caracteristica.

Organizati aplicatia dupa functii

Pentru o aplicatie web complexa, este de obicei greu de inteles cum functioneaza impreuna diferite parti. Dezvoltatorii originali trebuie sa deseneze arhitecturi, sa scrie documente pentru a descrie sistemul, astfel incat ceilalti sa poata intelege. Dar mentinerea lor este foarte dificila, deoarece atunci cand proiectul evolueaza, documentele nu evolueaza singure.

Oamenii trebuie sa le actualizeze la timp, astfel incat sa nu induca in eroare in timp ce nu ajuta. Deci, daca proiectul in sine se autodescrie? O arhitectura orientata pe caracteristici este utila in acest sens.

Deoarece am grupat componentele, actiunile, stocarile in caracteristici, nu trebuie sa ne gandim la modul in care aceste parti mici functioneaza impreuna, ci luam in considerare doar modul in care functiile functioneaza impreuna pentru a construi intreaga aplicatie. Functiile sunt unitati mult mai mari decat artefacte tehnice pure, cum ar fi componente, actiuni sau modele. Analizand dependentele dintre caracteristici, sistemul ar putea genera automat diagrame inteligibile si precise pentru ca dezvoltatorii sa invete sau sa revizuiasca proiectul.

Implementarea folosind React, Redux, React router

Ideea este dezvoltata prin crearea de aplicatii folosind routerul React, Redux si React. Iata arhitectura generala:

Exemplu de cuvant adevarat

Sa comparam mai jos doua diagrame, din portalul Rekit, una contine relatii intre artefacte mici, iar cealalta contine doar relatie intre caracteristici. Este evident ca primul este prea complicat pentru a fi inteles. De fapt, de obicei nu trebuie sa ne preocupam de complexitatea din interiorul unei caracteristici, deoarece este mica si nu impiedica sa intelegem intreaga aplicatie.

Toate dependentele sunt vizibile

Doar dependente intre caracteristici

Prin aceasta abordare, separam preocuparile unui proiect de anvergura. Fiecare caracteristica este auto-gestionabila si decuplata de altele. Pentru a intelege intregul proiect, ne uitam la relatiile dintre caracteristici, pentru a intelege ca privim doar intr-o singura caracteristica mica.

Dependente dure si moi

Deoarece functiile trebuie sa functioneze impreuna, nu putem evita dependentele dintre functii. De fapt, o functie noua este foarte posibil sa se bazeze pe alte caracteristici existente. Dar ar trebui, de asemenea, sa facem caracteristicile cat mai individuale pe cat posibil. Si ar trebui sa evitam dependentele circulare dure. Aici mentionam dependente dificile, opus avem si dependente usoare. Mai jos este ceea ce definim greu si moale:

Cand caracteristica A se bazeaza pe caracteristica B, adica B nu va functiona fara A. Spunem ca dependenta de la B la A este o dependenta dura.

De exemplu, caracteristica diagrama ofera vizualizarea proiectului, utilizeaza date din caracteristica acasa, daca nu exista functie acasa, diagrama nu functioneaza. Apoi spunem ca diagrama depinde cu greu de acasa.

Cand caracteristica A foloseste unele artefacte de la B (depinde de B) pentru a oferi noi capabilitati, dar daca nu exista B, A functioneaza in continuare, pur si simplu eliminand codul aferent. Apoi spunem ca dependenta de la A la B este o dependenta simpla.

De exemplu, in aplicatia portal Rekit, caracteristica Rekit-cmds ofera posibilitatea de a gestiona elemente Rekit, dar caracteristica de acasa trebuie sa furnizeze elemente de meniu ca intrari. Apoi spunem ca acasa depinde usor de functia Rekit-cmds. Dependentele usoare ar putea fi de obicei respinse prin proiectarea unor mecanisme de extensie. De exemplu, daca functia de acasa permite altor functii sa inregistreze elemente de meniu, atunci nu vor exista dependente de acasa la Rekit-cmds. Cu toate acestea, o arhitectura de extensie adauga intotdeauna multa complexitate sistemului, daca nu este foarte necesara, preferam dependente usoare, astfel incat sistemul sa fie mai usor de inteles sau de depanat.

In diagramele portalului Rekit, putem gasi cu usurinta in linii solide si dependente moi in linii punctate. Vedeti mai jos, cand mouse-ul peste caracteristica Rekit cmds, putem vedea dependentele hard si soft.

Dependente ale functiei Rekit cmds

Concluzie

Acest articol descrie gandul de a construi o aplicatie dupa caracteristici. Toate artefactele de mica tehnica ar trebui grupate pe caracteristici, astfel incat intregul sistem sa fie scalabil si intretinibil.