Applicatie architectuur

Een gangbare architectuur voor het opdelen van applicatie functionaliteit is die van het groeperen van functionaliteit naar aandachtsgebied. Onderstaande afbeelding geeft de plaat weer die de Patterns & Practices groep van Microsoft hiervoor gebruikt binnen hun Microsoft Application Architecture Guide (2nd edition). Dit artikel geeft een samenvatting weer van de essentie van deze architecturele opdeling van een applicatie.

 

Ontwerp principes

Hanteer bij het ontwerpen van een applicatie de volgende vijf principes:

1. Scheiden van verantwoordelijkheid (Separation of concerns). Deel de toepassing op in afzonderlijke functies met zo min mogelijk overlap.
2. Afzonderlijke verantwoordelijkheid (Single Responsibility) principe. Elke component- of module moet verantwoordelijk zijn voor een bepaalde functie / functionaliteit of over de samenvoeging van samenhangende functionaliteit.
3. Het principe van minste kennis (Principle of Least Knowledge). Een component of een object moet niet weten over interne informatie van andere objecten of onderdelen.
   Herhaal jezelf niet. Specifieke functionaliteit dient alleen in een component geimplementeerd te worden. De functionaliteit dient dus niet gedupliceerd te worden in andere componenten.
4. Minimaliseer het vooraf ontwerp. Ontwerp alleen hetgene wat nu nodig is.

Hieronder zal op de essentie van iedere laag ingegaan worden en diverse aandachtspunten behandeld worden omtrent validaties.

Cross cutting concerns

Cross cutting concerns bestaan uit gebieden van het ontwerp die niet zijn toe te wijzen aan een bepaalde laag uit de applicatie. Denk hierbij aan:

• Logging. Een log mechanisme waarmee iedere laag kan loggen naar een gezamenlijke log locatie of naar een separate log locatie en dat op dusdanige manier is opgezet dat acties gevolgd kunnen worden door de gehele applicatie heen. Aandachtspunt hierbij is dat er genoeg informatie gelogd kan worden om acties te reproduceren zonder dat er gevoelige informatie wordt vastgelegd.
• Authenticatie / Autorisatie. Een mechanisme voor authenticatie en autorisatie om identiteiten en rechten door te geven over de lagen heen.
• Exception Management. Een exceptie management mechanisme dat over de lagen heen werkt. Hierbij worden excepties afgevangen op functionele, logische en fysieke grensen van het systeem op een dusdanige manier dat er geen gevoelige informatie wordt getoond aan eindgebruikers.
• Communication. Een communicatie aanpak tussen de diverse lagen. Aandachtspunten zijn het minimaliseren van netwerk verkeer en het afschermen van gevoelige data dat over het netwerk wordt uitgewisseld.
• Caching. Een caching infrastructuur waarmee data gecached kan worden in de presentatie laag, business laag en data access laag.

Presentation Layer

De presentatie laag bevat de functionaliteit waarmee een eindgebruiker interacteert met het systeem en ontsluit hiermee de business layer. Het bestaat uit componenten voor invoer en weergave van gegevens en voor het beheren van de gebruikersinteractie.

De presentatie laag bevat de volgende onderdelen:

• User Interface componenten. Dit zijn visuele elementen die gebruikt worden om informatie weer te geven en om gebruikers invoer te accepteren.
  
• Presentation Logic componenten. Presentatie logica is de code waarmee het logische gedrag en de structuur van de toepassing worden vastgelegd in een vorm die onafhankelijk is van een specifieke gebruikers interface. Wanneer gebruik wordt gemaakt van het Separated Presentation pattern (zoals MVC en MVP) bevat deze (sub)laag de onderdelen voor de Presenter, Presentation Model en ViewModel componenten. De presentatie laag mag ook Presentation Layer Model componenten bevatten die business logica en data encapsuleren in een vorm die gemakkelijk is te consumeren door de presentatie laag.

Omtrent validaties is het volgende te melden voor deze laag:

• Input validaties dienen in de presentation layer plaats te vinden en business logica validaties in de business layer. Indien de presentation en business layer fysiek zijn gescheiden dienen de business logica validaties ook op de presentatie layer plaats te vinden (gespiegeld) om ervoor te zorgen dat de gebruiksvriendelijkheid en performance eisen gehaald kunnen worden. Dit kan bereikt worden door gebruik te maken van meta data of door het gebruik van een gemeenschappelijk validatie component in beide lagen.
• De validaties moeten de invoer van gevaarlijke invoer beperken / tegen houden.
• Handel validatie fouten correct af en toon geen gevoelige informatie in (fout)boodschappen.

Services Layer

Wanneer een applicatie zowel diensten aan andere applicaties en aan eindgebruikers beschikbaar stelt  is het een gebruikelijke aanpak om dit te doen via een services laag. Deze laag ontsluit de business functionaliteit van de applicatie.

De service layer bevat de volgende onderdelen:

• Service interfaces. Services ontsluiten een service interface waarnaar alle inkomen boodschappen worden gestuurd. Een service interface is een vorm van een facade die de business logica uit de applicatie ontsluit aan potentiele afnemers. 
  
• Message types. Bij het uitwisselen van gegevens over de service laag, worden gegevensstructuren omsloten door bericht structuren die ondersteuning bieden voor verschillende soorten bewerkingen. De service laag bevat vaak ook data typen en contracten die het data formaat definieren van de berichten.

Omtrent validaties is het volgende te melden voor deze laag:

• Centraliseer je validatie aanpak om testbaarheid en hergebruik te maximaliseren. 
• De validaties moeten de invoer van gevaarlijke invoer beperken / tegen houden. Neem aan dat alle gebruikersinvoer verdacht is. Valideer op lengte, range, formaat en type.
• Overweeg het gebruik van schema validatie voor boodschappen.

Business Layer

De business layer implementeert de kernfunctionaliteit van het systeem en bevat de bedrijfslogica. Het ontsluit deze functionaliteit door middels van interfaces.

De business layer bevat de volgende onderdelen:

• Application facade. Dit optionele component biedt meestal een vereenvoudige weergave op de achterliggende business componenten. Vaak gebeurd dit door het samenvoegen van diverse componenten in een enkele operatie. Hierdoor hoeft de aanroeper geen kennis te hebben van de business componenten en de relaties hier tussen.
  
• Business Logic componenten. Business logica wordt gedefinieerd als elke applicatie logica dat betrokken is bij het ophalen, verwerken, transformeren en beheren van applicatie data, de toepassing van bedrijfsregels en beleid, en het waarborgen van data consistentie en data validiteit. Om de herbruikbaarheid te verhogen van business logica componenten dienen deze niet logica te bevatten die specifiek is voor een use case / use story.
  
  Business logic componenten kunnen verbijzonderd worden naar de volgende onderdelen:
  
• Business Workflow componenten. Nadat de UI-componenten van de gebruiker de vereiste gegevens verzameld hebben en aan de business logic laag hebben doorgeven, kan de toepassing deze gegevens gebruiken voor het uitvoeren van een bedrijfsproces. Veel bedrijfsprocessen bestaan uit meerdere stappen die moeten worden uitgevoerd in de juiste volgorde, en kunnen met elkaar communiceren via een orkestratie. Business workflow onderdelen definieren en coordineren langlopende, uit meerdere onderdelen bestaande bedrijfsprocessen, en kunnen worden geimplementeerd met business process management tools.
  
• Business Entity componenten. Business entities, ook wel business objecten genoemd, encapsuleren de business logica en data die nodig zijn voor het representateren van echte elementen als een klant en een order binnen de applicatie. Deze componenten slaan waarden op en ontsluiten deze via properties, bevatten en managen business data welke in gebruik is bij de applicatie en bieden stateful geprogrameerde toegang tot de business data en gerelateerde functionaliteit. Busines entities valideren ook data welke opgeslagen worden binnen de entiteit en encapsuleren de business logica om zo zorg te dragen voor de consistentie en het implementeren van bedrijfsregels en gedrag.

Omtrent validaties is het volgende te melden voor deze laag:

• Valideer alle input en method parameters. Ook als deze al zijn gevalideerd door de presentation layer.
• Centraliseer je validatie aanpak om testbaarheid en hergebruik te maximaliseren.
• De validaties moeten de invoer van gevaarlijke invoer beperken / tegen houden. Neem aan dat alle gebruikersinvoer verdacht is. Valideer op lengte, range, formaat en type.

Data Access Layer

De data access layer ontsluit data opgeslagen binnen de grenzen van het systeem en data van externe systemen. Het ontsluit de data middels algemene interfaces die aangesproken kunnen worden door componenten uit de business layer.

De data access layer bevat de volgende onderdelen:

• Data Access componenten. Deze componenten abstreheren de logica die nodig is voor het benaderen van de onderliggende data bronnen. Ze centraliseren algemene functies voor toegang tot data om zo de applicatie gemakkelijker te configureren en te beheren.
  
• Service Agents. Wanneer een business component toegang nodig heeft tot data die aangeboden wordt door een externe service dan dient er code geimplementeerd te worden voor de communicatie met deze service. Service Agents implementeren data components welke de vereisten voor communicatie met de externe service isoleren van de rest van de applicatie. Daarnaast kan er in de service agent extra functionaliteit geimplementeerd worden voor zaken als  caching, offline support en standaard mapping tussen het data formaat van de service en het formaat dat de eigen applicatie gebruikt.

Omtrent validaties is het volgende te melden voor deze laag:

• Valideer alle data die de data layer ontvangt van iedere aanroeper. Verifieer dat je NULL waarden correct afhandeld en ongeldige karakters er uit filtert.
• Het doel van de gegevens bepaalt de validatie strategie. Als de data bivoorbeeld gebruikt wordt voor het opbouwen van een dynamische SQL query dan dient deze geverifieerd te worden op karakters en patronen die gebruikt worden voor een SQL injectie aanval.
• Geef informatieve (fout)meldingen terug als een validatie faalt.