Key Concepts
Merk in figuur 1-2 op dat elk van de lagen in de architectuur is gemarkeerd als gesloten. Dit is een zeer belangrijk concept in het gelaagde architectuur patroon. Een gesloten laag betekent dat als een verzoek van laag naar laag gaat, het door de laag er direct onder moet gaan om bij de volgende laag eronder te komen. Bijvoorbeeld, een verzoek dat afkomstig is van de presentatielaag moet eerst door de bedrijfslaag en vervolgens door de persistentielaag voordat het uiteindelijk bij de databaselaag terechtkomt.
Figuur 1-2. Gesloten lagen en toegang tot verzoeken
Dus waarom zou u de presentatielaag geen directe toegang geven tot de persistentielaag of de databaselaag? Directe toegang tot de database vanuit de presentatielaag is immers veel sneller dan het doorlopen van een heleboel onnodige lagen alleen maar om database-informatie op te halen of op te slaan. Het antwoord op deze vraag ligt in een sleutelbegrip dat bekend staat als isolatielagen.
Het concept van isolatielagen houdt in dat wijzigingen in de ene laag van de architectuur in het algemeen geen invloed hebben op componenten in andere lagen: de wijziging is geïsoleerd tot de componenten in die laag, en mogelijk een andere bijbehorende laag (zoals een persistentie laag die SQL bevat). Als je de presentatie laag direct toegang geeft tot de persistentie laag, dan zouden wijzigingen in SQL binnen de persistentie laag invloed hebben op zowel de bedrijfslaag als de presentatie laag, waardoor een zeer strak gekoppelde applicatie ontstaat met veel onderlinge afhankelijkheden tussen componenten. Dit soort architectuur wordt dan erg moeilijk en duur om te veranderen.
Het concept van isolatielagen betekent ook dat elke laag onafhankelijk is van de andere lagen, en daardoor weinig of geen kennis heeft van de innerlijke werking van andere lagen in de architectuur. Om de kracht en het belang van dit concept te begrijpen, denk aan een grote refactoring inspanning om het presentatie raamwerk om te zetten van JSP (Java Server Pages) naar JSF (Java Server Faces). Ervan uitgaande dat de contracten (bijvoorbeeld, model) die worden gebruikt tussen de presentatie laag en de business laag hetzelfde blijven, wordt de business laag niet beïnvloed door de refactoring en blijft volledig onafhankelijk van het type user-interface framework dat wordt gebruikt door de presentatie laag.
Terwijl gesloten lagen isolatielagen mogelijk maken en daardoor helpen om veranderingen binnen de architectuur te isoleren, zijn er momenten waarop het zinvol is om bepaalde lagen open te laten zijn. Stel bijvoorbeeld dat u een shared-services laag wilt toevoegen aan een architectuur die gemeenschappelijke service componenten bevat die worden benaderd door componenten in de business laag (b.v. data en string utility classes of auditing en logging classes). Het maken van een services laag is in dit geval meestal een goed idee omdat het architectonisch de toegang tot de gedeelde services beperkt tot de bedrijfslaag (en niet de presentatielaag). Zonder een aparte laag is er architectonisch niets dat de presentatie laag beperkt in de toegang tot deze gemeenschappelijke diensten, wat het moeilijk maakt om deze toegangsbeperking te regelen.
In dit voorbeeld zou de nieuwe services-laag waarschijnlijk onder de bedrijfslaag worden geplaatst om aan te geven dat componenten in deze services-laag niet toegankelijk zijn vanuit de presentatielaag. Dit levert echter een probleem op, omdat de bedrijfslaag nu door de services laag heen moet om bij de persistentie laag te komen, wat helemaal niet logisch is. Dit is een eeuwenoud probleem met de gelaagde architectuur, en wordt opgelost door open lagen binnen de architectuur te creëren.
Zoals geïllustreerd in Figuur 1-3, is de services laag in dit geval gemarkeerd als open, wat betekent dat verzoeken worden toegestaan om deze open laag te omzeilen en direct naar de laag eronder te gaan. In het volgende voorbeeld mag de bedrijfslaag, omdat de services laag open is, er nu omheen en direct naar de persistentie laag gaan, wat volkomen logisch is.
Figuur 1-3. Open lagen en request flow
Het gebruik van het concept van open en gesloten lagen helpt bij het definiëren van de relatie tussen architectuurlagen en request flows en voorziet ontwerpers en ontwikkelaars ook van de nodige informatie om de verschillende toegangsbeperkingen voor lagen binnen de architectuur te begrijpen. Als niet goed wordt gedocumenteerd of gecommuniceerd welke lagen in de architectuur open en gesloten zijn (en waarom), leidt dit meestal tot strak gekoppelde en broze architecturen die zeer moeilijk te testen, onderhouden en implementeren zijn.