{"id":18706,"date":"2024-06-24T15:38:44","date_gmt":"2024-06-24T13:38:44","guid":{"rendered":"https:\/\/connectconsulting.be\/?p=18706"},"modified":"2024-06-24T15:49:04","modified_gmt":"2024-06-24T13:49:04","slug":"clean-architecture-2","status":"publish","type":"post","link":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/","title":{"rendered":"Clean Architecture"},"content":{"rendered":"<p><span style=\"color: #000000;\"><strong>1. What is Architecture?<\/strong><\/span><\/p>\n<ul>\n<li><span style=\"color: #808080;\"><strong>Layers &amp; Access:<\/strong> In softwareontwikkeling verwijst architectuur naar meer dan alleen hoe de code is gestructureerd of georganiseerd. Het beschrijft de choreografie van hoe verschillende lagen binnen een systeem met elkaar interactie hebben en hoe informatie door deze lagen stroomt. Wanneer je de toegang tussen deze lagen afbakent, ontstaat er een architectuur.<\/span><\/li>\n<li><span style=\"color: #808080;\"><strong>Principles &amp; Architecture:<\/strong> Hoewel architectuur vaak ontwerpprincipes zoals SOLID omvatten en verschillende ontwerppatronen omarmen, vormen deze elementen op zichzelf geen architectuur.<\/span><\/li>\n<\/ul>\n<p><span style=\"color: #808080;\">Echter: leidende principes en patronen zijn onvermijdelijk voor een robuuste architectuur. <\/span><span style=\"color: #808080;\">Deze patronen zijn slechts een hulpmiddelen die helpen bij het realiseren van een bredere structurele visie. Ze vormen op zichzelf niet de architectuur.<br \/>\n<\/span><br \/>\n<span style=\"color: #808080;\">Doel van architectuur? = Separation of concerns<\/span><br \/>\n<span style=\"color: #808080;\">Waarom? Het maakt het systeem beter uitbreidbaar, onderhoudbaar en makkelijker voor nieuwe medewerkers om zich in te werken. Bovendien, als een applicatie het separation of concerns principe volgt, zijn de kosten van iteraties (de tijd die nodig is om een nieuwe functie toe te voegen) lager doordat de codebasis gestructureerd is en de componenten ervan ontkoppeld zijn.<\/span><\/p>\n<p><strong>2. Quest for an architecture<\/strong><\/p>\n<p><span style=\"color: #ff9900;\"><strong>2.1 Basic Architecture<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Je maakt een leeg project, maakt wat directories aan en structureert zo je bestanden. Geen libraries, lagen of goed gedefinieerde regels voor het splitsen van verantwoordelijkheden. Gewoon zorgen dat het werkt. Perfect voor Proof of Concepts (POC) of demo-applicaties.<\/span><\/p>\n<p><span style=\"color: #808080;\">Je kunt kiezen voor een basisarchitectuur als je zo snel mogelijk een MVP (Minimum Viable Product) wilt lanceren en je geen extra tijd en middelen wilt besteden aan het leren van principes van andere architectuurmodellen. Kies altijd voor separation of concerns. Ontwikkel geen slechte gewoontes als programmeur! Je code is kunst, maak er dan ook een kunstwerk van.<\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>2.2 N-Tier Architecture<\/strong><\/span><\/p>\n<p><img decoding=\"async\" class=\"alignnone wp-image-18655\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/1-300x56.png\" alt=\"\" width=\"439\" height=\"82\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/1-300x56.png 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/1.png 479w\" sizes=\"(max-width: 439px) 100vw, 439px\" \/><br \/>\n<span style=\"color: #808080;\">= het verdelen van je code in lagen (tiers), waarbij elke laag een afzonderlijk aandachtsgebied beheert.<br \/>\nDe \u201cN\u201d van n-tier geeft aan dat je zoveel lagen kunt hebben als je wilt, bijvoorbeeld 3-tier, 4-tier (Sidenote: sommigen zeggen dat het staat voor Neuropsychopharmacologie).<\/span><br \/>\n<span style=\"color: #808080;\">Presentatielaag: dit is de interface die door de cli\u00ebnt wordt gebruikt om met uw applicatie te communiceren (client-facing-layer). Het kan verschillende vormen aannemen, van mobiele of desktopapplicaties tot een API of een command line.<\/span><br \/>\n<span style=\"color: #808080;\">Bijvoorbeeld: als u een aparte applicatie voor de UI heeft, gebouwd met Angular of React bijvoorbeeld, die communiceert met een backend-API, dan zal de API zelf uw presentatielaag zijn (U behandelt de Angular-app als client, aangezien het een volledig andere applicatie is).<\/span><\/p>\n<ul>\n<li><strong>Presentatie<\/strong>\n<ul>\n<li><span style=\"color: #808080;\">Het roept een business logic laag aan, die zorgt voor de verwerking van verzoeken;<\/span><\/li>\n<li><span style=\"color: #808080;\">Alleen zaken die direct verband houden met de presentatie (API-configuraties, routes, &#8230;) bevinden zich hier;<\/span><\/li>\n<li><span style=\"color: #808080;\">Laat de bedrijfslogica niet naar deze laag doordringen, houd het schoon van bedrijfsregels !<\/span><\/li>\n<\/ul>\n<\/li>\n<li><strong>Business Logic Layer (BLL)<\/strong>\n<ul>\n<li><span style=\"color: #808080;\">De Business Logic van uw applicatie bevindt zich hier, samen met alles behalve de ORM en andere zaken die betrekking hebben op het verkrijgen van gegevens, omdat ze deel uitmaken van uw volgende laag =&gt; DAL;<\/span><\/li>\n<li><span style=\"color: #808080;\">Omvat: services die worden gebruikt voor communicatie met externe systemen, zoals het verzenden van een e-mail, het pushen van een bericht naar een topic en dergelijke;<\/span><\/li>\n<li><span style=\"color: #808080;\">Als de BLL gegevens moet opslaan, ophalen, bijwerken of verwijderen zal deze de DAL aanspreken.<\/span><\/li>\n<\/ul>\n<\/li>\n<li><strong>Data Access Layer (DAL)<\/strong>\n<ul>\n<li><span style=\"color: #808080;\">Theoretisch gezien: het weet niets van andere lagen en kan op elk moment worden gewijzigd met een andere implementatie;<\/span><\/li>\n<li><span style=\"color: #808080;\">Vanwege de afhankelijkheid van de BLL van DAL, zal de Business Logic worden be\u00efnvloed en kunnen wijzigingen zich naar boven verspreiden, en dat is een beetje vreemd omdat alleen de business het BLL zou moeten, kunnen wijzigen;<\/span><\/li>\n<li><span style=\"color: #808080;\">Het wijzigen van de databaseprovider wordt niet bepaald door de business, het is een infrastructurele beslissing.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><span style=\"color: #808080;\">Let op de afhankelijkheden: presentatie =&gt; BLL =&gt; DAL.<\/span><\/p>\n<p><span style=\"color: #808080;\">Onze hele applicatie is afhankelijk van DAL als de kern van het systeem (= Database Driven Design). Het lijkt niet echt een goed idee om deze applicatie afhankelijk te maken van DAL.<\/span><br \/>\n<span style=\"color: #808080;\">Uitgaande van het idee dat onze applicatie een business probleem oplost, zou het dan niet beter zijn om de BLL te verheffen en deze de kern van ons systeem te maken en het onafhankelijk te maken van andere lagen?<\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>2.3 Hexagonal Architecture<\/strong><\/span><\/p>\n<p><img fetchpriority=\"high\" decoding=\"async\" class=\"alignnone wp-image-18658\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/2-300x140.png\" alt=\"\" width=\"400\" height=\"187\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/2-300x140.png 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/2.png 509w\" sizes=\"(max-width: 400px) 100vw, 400px\" \/><br \/>\n<span style=\"color: #808080;\">= BLL is de kern. Binnen de BLL defini\u00ebren we interfaces die worden ge\u00efmplementeerd door andere externe componenten.<\/span><br \/>\n<span style=\"color: #808080;\">Voorbeeld: Abstracties worden vastgelegd in de BLL (Irepository). Implementaties worden geleverd door de componenten (in dit geval Data Access).<\/span><\/p>\n<p><span style=\"color: #808080;\">Dependency Inversion &amp; Dependency Injection helpen ons om de implementatie van Irepository op runtime aan te bieden en zo te voorkomen dat DA wordt genoemd tijdens het compileren. Nul verwijzingen naar andere componenten van onze applicatie. Het is afhankelijk van niets behalve de BL.<\/span><\/p>\n<p><span style=\"color: #808080;\">Haal alle andere afhankelijkheden van externe systemen eruit (vb.: IEmailService, IFileManager, &#8230;). Abstraheer elke afhankelijkheid van een ander systeem door een interface binnen de BL te hebben, en de implementatie ervan als onderdeel van een ander component.<\/span><\/p>\n<p><span style=\"color: #808080;\">In deze context wordt de interface gedefinieerd door BL, een Poort genoemd en de implementatie die door de andere componenten wordt geleverd, Adapter (daarom vind je in sommige documentatie de Hexagonale architectuur genoemd als Poorten en Adapters). <\/span><span style=\"color: #808080;\">Primaire adapters (die in de BL roepen) en secundaire adapters (die op runtime worden aangeroepen door de BL, zoals DA, E-mail). <\/span><span style=\"color: #808080;\">De presentatielaag uit het N-tier model wordt vertegenwoordigd door primaire adapters in de context van het Hexagonale model. Ze fungeren als een ingress-controller en zijn cli\u00ebntgerichte adapters (API, UI, Command Line). Secundaire adapters zijn degene die door de BL worden aangeroepen en communicatie met externe systemen afhandelen.<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Primaire adapters drijven \u2013 ze doen oproepen naar de BL<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Secundaire adapters worden gedreven \u2013 BL roept ze op vanwege omgekeerde controle<\/span><\/p>\n<p><span style=\"color: #808080;\">Dit noemen we een Domain Driven Design (DDD).<\/span><br \/>\n<span style=\"color: #808080;\">Probleem: dat is cool, maar tientallen componenten hebben is eigenlijk niet het beste idee. Laten we een manier vinden om ze te groeperen!<\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>2.4 Onion Architecture<\/strong><\/span><\/p>\n<p><img decoding=\"async\" class=\"alignnone size-medium wp-image-18661\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/3-300x263.png\" alt=\"\" width=\"300\" height=\"263\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/3-300x263.png 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/3.png 424w\" sizes=\"(max-width: 300px) 100vw, 300px\" \/><\/p>\n<p><span style=\"color: #808080;\">= omdat het de ui-structuur nabootst. De lagen gaan rondom de kern. Dependencies gaan naar binnen \u2013 en van de buitenste lagen naar de binnenste. Het hele idee van de Onion structuur is om de Business Logic in de kern te plaatsen, en andere lagen ervan afhankelijk te maken door gebruik te maken van Dependency Inversion &amp; Dependency Injection.<\/span><\/p>\n<p><span style=\"color: #808080;\">Twee bijzonderheden:<\/span><\/p>\n<ul>\n<li><strong>Primaire adapters<\/strong> <span style=\"color: #808080;\">(client-facing-ones) maken nu deel uit van de presentation layer, terwijl de secundaire adapters (die communiceren met externe systemen) deel uitmaken van de infrastructure layer.<\/span><\/li>\n<li><strong>De Business Logic<\/strong> <span style=\"color: #808080;\">(BL) is nu verdeelt in N-lagen. N omdat het aantal lagen per geval kan vari\u00ebren. De kern wordt vertegenwoordigd door een domain layer. Deze laag heeft geen dependencies en bevat business models, entities, value objects, enumerations en andere business related objects (het volgen van DDD-principles is een good practice voor een goed ontwerp van de domainlaag). De lagen ertussen kunnen vari\u00ebren. Gewoonlijk zou je Domain Services (een ander concept van DDD) in een aparte laag rond het domain plaatsen, met enkele ports (interfaces) waarvan de implementatie zich in de buitenste infrastructuurlaag bevindt &#8211; (Als je CQRS zou volgen, kunnen command &amp; query hun eigen laag rond Domain Services hebben en als je het Use-Case-Pattern gebruikt, zou je deze ook weer in een aparte laag plaatsen enz). Er zijn geen strikte regels over hoeveel lagen je kunt hebben.<\/span><\/li>\n<\/ul>\n<p><span style=\"color: #ff9900;\"><strong>2.5 Clean Architecture<\/strong><\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-18664\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/4-300x223.png\" alt=\"\" width=\"362\" height=\"269\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/4-300x223.png 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/4.png 407w\" sizes=\"(max-width: 362px) 100vw, 362px\" \/><br \/>\n<span style=\"color: #808080;\">Voegt een beetje regulering toe aan de onion structuur. Het stelt dat de domain layer bedoeld is voor enterprise-wide business rules die het minst waarschijnlijk zullen veranderen (entities, enumerations, value objects, core domain objects). Daaromheen bevindt zich de application layer, die alles omvat dat te maken heeft met hoe de business opereert. Ook is dit waar de ports (interfaces) zich bevinden. De infrastructure layer bevat adapters (implementaties) die fungeren als gateways naar externe systemen.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>KEY Principles:\u00a0<\/strong><\/span><\/p>\n<ul>\n<li><strong>Dependency Rule:<\/strong><span style=\"color: #808080;\"> dependencies moeten altijd naar binnen wijzen, richting de kern van de business logic. Binnenste lagen mogen niet afhankelijk zijn van de buitenste lagen.<\/span><\/li>\n<li><strong>Separation of Concerns:<\/strong> <span style=\"color: #808080;\">elke laag heeft een specifieke verantwoordelijkheid en de zorgen van de ene laag mogen niet doorsijpelen naar een andere.<\/span><br \/>\n<span style=\"color: #808080;\">Deze scheiding helpt bij het behouden van modulariteit en testbaarheid.<\/span><\/li>\n<li><strong>Independence of Frameworks:<\/strong> <span style=\"color: #808080;\">de kern van de business logic mag niet afhankelijk zijn van de specifieke frameworks of tools. Frameworks en externe tools moeten zich aanpassen aan de applicatie en niet andersom.<\/span><\/li>\n<li><span style=\"color: #808080;\">Kan leiden tot betere onderhoudbare, schaalbare en testbare code.<\/span><\/li>\n<\/ul>\n<p><span style=\"color: #808080;\"><strong>PROS:<\/strong><\/span><\/p>\n<ul>\n<li><strong>Modularity and Maintainability<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Voordeel:<\/em> Clean Architecture bevordert modulariteit door verantwoordelijkheden in afzonderlijke lagen te scheiden. Dit maakt de codebasis beter onderhoudbaar en maakt het gemakkelijker om updates of wijzigingen aan specifieke componenten door te voeren, zonder de gehele applicatie te be\u00efnvloeden.<\/span><\/li>\n<li><strong>Testablity<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Voordeel:<\/em> s<\/span><span style=\"color: #808080;\">eparation of Concerns vergemakkelijkt unit testing. De Business Logic in de kern laag kan onafhankelijk van external dependencies worden getest, wat leidt tot robuustere en betrouwbaardere tests.<\/span><\/li>\n<li><strong>Independence of Frameworks<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Voordeel:<\/em> de kern van de business logic is niet tightly coupled aan specifieke frameworks of libraries. Deze onafhankelijkheid maakt het gemakkelijker om frameworks te wisselen of te upgraden zonder de kernfunctionaliteiten te be\u00efnvloeden.<\/span><\/li>\n<li><strong>Flexibility<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Voordeel:<\/em> Clean Architecture biedt flexibiliteit bij het kiezen van technologie\u00ebn voor verschillende lagen.<\/span><br \/>\n<span style=\"color: #808080;\"><em>Bijvoorbeeld<\/em>: je kunt wisselen van verschillende web frameworks, databases of UI frameworks zonder grote wijzigingen in de kern van de business logic.<\/span><\/li>\n<li><strong>Scalability<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Voordeel:<\/em> de modulaire structuur van Clean Architecture zorgt voor betere scalability. Het is gemakkelijker om verschillende delen van de applicatie onafhankelijk te scalen, en teams kunnen werken aan specifieke lagen zonder anderen te hinderen.<\/span><\/li>\n<\/ul>\n<p><span style=\"color: #808080;\"><strong>CONS:<\/strong><\/span><\/p>\n<ul>\n<li><strong>Complexity<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Nadeel:<\/em> het implementeren van Clean Architecture kan extra complexiteit introduceren, vooral in de beginfase van de ontwikkeling. De scheiding van verantwoordelijkheden kan leiden tot meer bestanden en mappen, wat overweldigend kan zijn voor kleinere projecten.<\/span><\/li>\n<li><strong>Learning Curve<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Nadeel:<\/em> Developers die nieuw zijn met Clean Architecture, kunnen te maken krijgen met een leercurve. Het begrijpen van de principes en het correct implementeren van de architectuur kan tijd en moeite kosten.<\/span><\/li>\n<li><strong>Boilerplate code<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Nadeel:<\/em> Clean Architecture kan het schrijven van meer boilerplate-code met zich meebrengen, met name bij het mappen van gegevens tussen lagen. Dit kan leiden tot een langere ontwikkeltijd, hoewel wordt beweerd dat de voordelen op het gebied van onderhoudbaarheid opwegen tegen dit nadeel.<\/span><\/li>\n<li><strong>Over-Engineering for simple projects<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Nadeel:<\/em> Clean Architecture kan overdreven zijn voor eenvoudige of kleine projecten waar de voordelen van separation of concerns en modulariteit niet zo duidelijk naar voren komen. In dergelijke gevallen is een eenvoudigere architectuur meer geschikt.<\/span><\/li>\n<li><strong>Performance overhead<\/strong><br \/>\n<span style=\"color: #808080;\"><em>Nadeel:<\/em> de extra lagen en abstracties in Clean Architecture kunnen enige performance overhead introduceren. In applicaties waar performance van cruciaal belang is, kunnen zorgvuldige overwegingen en optimalisatie noodzakelijk zijn.<\/span><\/li>\n<\/ul>\n<p><strong><span style=\"color: #808080;\"><span style=\"color: #000000;\">Conclusie:<\/span><br \/>\n<\/span><\/strong><span style=\"color: #808080;\">Voordelen op het gebied van onderhoudbaarheid, testbaarheid en flexibiliteit. Maar het is essentieel om deze voordelen af te wegen tegen mogelijk nadelen, vooral in de context van de specifieke omvang en complexiteit van het project. Het is geen one-size-fits-all oplossing, en Developers moeten afwegingen overwegen op basis van de vereisten en beperkingen van het project.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>De Essentie:<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Clean Architecture is niet zomaar een andere architectuurstijl; het is een filosofie, een diepgaande benadering om systemen te ontwerpen met prioriteit voor onderhoudbaarheid en schaalbaarheid. Het hart van Clean Architecture wordt gevormd door de business regels \u2013 onbevlekt en puur \u2013 met externe functionaliteiten, zoals databases en UI aan de rand, ervoor zorgend dat wijzigingen in het ene onderdeel de andere niet negatief be\u00efnvloed.<\/span><\/p>\n<p><span style=\"color: #808080;\">Clean Architecture pleit voor een principe gedreven benadering boven een autoritaire, waarbij softwareontwikkelaars worden aangemoedigd om de essentie ervan te internaliseren om daaruit veerkrachtige systemen te cre\u00ebren.<\/span><\/p>\n<p><span style=\"color: #000000;\"><strong>3. Common mistakes and pitfalls<\/strong><\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>3.1 Entity: Misunderstanding &amp; clarifications<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Zowel Clean Architectrure als DDD gebruiken de term \u201cEnity\u201d in software design. Toch verschillen ze van elkaar. <\/span><span style=\"color: #808080;\">In Clean Architecture encapsulaten de entiteiten cruciale business logic en worden ze puur gehouden, dat wil zeggen vrij van externe invloeden zoals database. <\/span><span style=\"color: #808080;\">In DDD benadrukken entiteiten het belang van een unieke identiteit binnen de begrensde context en zijn ze in staat om rijker gedrag en zelfs complexe relaties met andere entiteiten te encapsuleren.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>Veel gemaakte fouten &amp; hun gevolgen<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Veel ontwikkelaars, voor diegenen die bekend zijn met Object-Relation Mapping (ORM) frameworks, zien entiteiten als eenvoudige datastructuren die database records weerspiegelen. Deze perceptie leidt hen ertoe om Anemic Entities te maken. Anemic Entity: objecten die geen gedrag bevatten en slechts dienen als een verzameling van getters en setters.<\/span><\/p>\n<p><span style=\"color: #000000;\"><strong>Waarom is dit verkeerd?<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Vermindert de cohesie: Anemic Entities worden losgekoppeld van de bewerkingen die erop worden uitgevoerd. In tegenstelling hiermee streven rich entities in Clean Architecture ernaar om gegevens en relevante bewerkingen samen te groeperen, wat zorgt voor een hogere cohesie.<\/span><\/p>\n<p><span style=\"color: #808080;\">Hier is de operatie applyDiscount losgekoppeld van de OrderAnemic-class en in een service geplaatst. Dit vermindert de cohesie omdat de gegevens (attributes van orderAnemic) en de bewerkingen op de gegevens (applyDiscount) gescheiden zijn.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>Violates Persistense Agnosticism:<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">De kern van de business logic wordt impliciet gekoppeld aan een specifieke persistence mechanism door entiteiten te cre\u00ebren die rechtstreeks de databasestructuren weerspiegelen. Dit staat in contrast met het principe van Clean Architecture om de kernlogica te scheiden van externe details.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-18670\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/6-300x69.jpg\" alt=\"\" width=\"378\" height=\"87\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/6-300x69.jpg 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/6.jpg 677w\" sizes=\"(max-width: 378px) 100vw, 378px\" \/><\/p>\n<p><span style=\"color: #808080;\">Het attribuut databaseRowVersion is rechtstreeks gekoppeld aan een veelgebruikte databasestructuur dat gebruikt wordt voor optimistic concurrency. Door dit in onze entiteit op te nemen, koppelen we de entiteit aan een specifiek persistence mechanism.<\/span><\/p>\n<p><span style=\"color: #808080;\">Verdunt de Business Logic: in plaats van de business logic binnen de entiteiten zelf te centraliseren verspreiden anemic entities de logica vaak over services of controllers, waardoor het systeem moeilijker te begrijpen en onderhouden is.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>Entity\u2019s Value Judgement:<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Het is cruciaal om te verduidelijken dat ik niet de anemic entities veroordeel. <\/span><span style=\"color: #808080;\">Ze vinden hun plaats in specifieke scenario\u2019s, vooral in gestroomlijnde applicaties met minder ingewikkelde domain logic of wanneer ze gecombineerd worden met bepaalde frameworks. Het belangrijkste is om het verschil te herkennen en een weloverwogen keuze te maken. <\/span><span style=\"color: #808080;\">Als je kiest voor een anemic entity, zorg er dan voor dat dit komt omdat het tastbare waarde toevoegt aan je scenario, en niet alleen als een standaardkeuze of een overgenomen gewoonte. In software architectuur, zoals in zoveel domeinen, is context van het grootste belang.<\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>3.2 Application Business Rules vs Enterprise Business Rules<\/strong><\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-18682\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Business-Rules-300x194.png\" alt=\"\" width=\"414\" height=\"268\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Business-Rules-300x194.png 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Business-Rules.png 727w\" sizes=\"(max-width: 414px) 100vw, 414px\" \/><br \/>\n<span style=\"color: #808080;\">De fundamentele kracht van Clean Architecture ligt in de duidelijke afbakening van verantwoordelijkheden, vooral als we het hebben over applicatie Business Rules en Enterprise Business Rules. Toch worden door veelvoorkomende misvattingen hun grenzen vaak vervaagd, wat leidt tot ontwerpfouten. <\/span><span style=\"color: #808080;\">Clean Architecture maakt het onderscheid tussen applicatie- en business logica. De eerste richt zich op de specifieke applicatievoorwaarden, waarbij vaak meerdere entiteiten of externe factoren betrokken zijn. De laatste draait om universele waarheden over entiteiten, die niet be\u00efnvloed worden door externe omstandigheden. Het herkennen van deze verschillen is essentieel voor een veerkrachtig en aanpasbaar systeem.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>3.2.1 Enterprise Business Rules: Heart of the Entity<\/strong><\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-18676\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/8-300x293.jpg\" alt=\"\" width=\"371\" height=\"362\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/8-300x293.jpg 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/8.jpg 684w\" sizes=\"(max-width: 371px) 100vw, 371px\" \/><br \/>\n<span style=\"color: #808080;\">Neem de entiteit \u2018Creditcard\u2019 in overweging. Op dit niveau zijn we ge\u00efnteresseerd in de inherente eigenschappen en gedragingen van de creditcard zelf, ongeacht externe factoren of specifieke applicatievoorwaarden. Hier zouden we:<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Het kaartnummerformaat valideren;<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> De vervaldatum controleren;<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Het formaat van de beveiligingscode verifi\u00ebren.<\/span><\/p>\n<p><span style=\"color: #808080;\">Alle operaties draaien uitsluitend om de creditcard-entiteit, waarbij de focus ligt op de intrinsieke eigenschappen of gedragingen. We hebben te maken met universele waarheden over wat een geldige creditcard vormt, zonder be\u00efnvloeding door externe omstandigheden of specifieke applicatiescenario\u2019s.<\/span><\/p>\n<p><span style=\"color: #808080;\"><strong>3.2.2 Application Business Rules (Use Cases)<\/strong><\/span><br \/>\n<span style=\"color: #808080;\">Een laag hoger vinden we de Use Cases dat onze Application Business rules orkestreert. Hier wordt de logica gestuurd door specifieke toepassingsvoorwaarden en scenario\u2019s, vaak met betrokkenheid van meerdere entiteiten of externe factoren.<\/span><\/p>\n<p><span style=\"color: #808080;\">Met hetzelfde creditcard voorbeeld zouden we hier:<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Controleren of de gebruiker die de kaart aanvraagt minstens 18 jaar oud is;<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Het land van de aanvrager bepalen en regio specifieke regels of aanbiedingen toepassen;<\/span><br \/>\n<span style=\"color: #808080;\"><span style=\"color: #ff9900;\">\u2022<\/span> Overwegen om te integreren met externe services om bv kredietcontroles uit te voeren.<\/span><\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-18679\" src=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/9-300x242.jpg\" alt=\"\" width=\"384\" height=\"310\" srcset=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/9-300x242.jpg 300w, https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/9.jpg 677w\" sizes=\"(max-width: 384px) 100vw, 384px\" \/><br \/>\n<span style=\"color: #808080;\">Hier wordt het service genoemd maar in Clean Architecture spreken ze meestal (en benoemen) van Use Cases.<\/span><br \/>\n<span style=\"color: #808080;\">Deze laag gaat verder dan de grenzen van een enkele entiteit. Het orkestreert interacties, volgt processen op en past contextuele business logic toe die uniek kunnen zijn voor een bepaalde toepassing of scenario. Het is waar de bredere business logic die relevant is voor de specifieke toepassing tot leven komt.<\/span><\/p>\n<p><span style=\"color: #ff9900;\"><strong>3.3 Common Mistakes<\/strong><\/span><\/p>\n<ul>\n<li><strong>Blurring the boundaries: <\/strong><span style=\"color: #808080;\">Developers verwarren vaak Application Business Rules met allesomvattende waarheden, die de Enterprise Business Rules overschaduwen. Deze misvatting wordt verergerd door een misvatting over entiteiten, die idealiter meer in lijn zouden moeten zijn met onveranderlijke feiten van Enterprise Business Rules.<\/span>\n<ul>\n<li><span style=\"color: #808080;\">Waarom dit fout is:<\/span><br \/>\n<strong>Ontbreekt aan flexibiliteit: <\/strong><span style=\"color: #808080;\">Het behandelen van Application Business Rules als constante waarheden belemmert de aanpasbaarheid van het systeem aan toekomstige veranderingen.<\/span><br \/>\n<strong>Risico&#8217;s voor integriteit: <\/strong><span style=\"color: #808080;\">Het niet onderscheiden van het verschil kan leiden tot onbedoelde schendingen van kern business logic tijdens wijzigingen in de applicatie.<\/span><\/li>\n<li><span style=\"color: #808080;\">Net als onze voorbeeldcode hierboven, het rechtstreeks toevoegen van de leeftijdscontrole van de gebruiker aan de creditcard class zou een fout zijn. Dit zou een ongepaste vermenging zijn van de Application Business Rules (leeftijdscontrole voor het aanvragen van een creditcard) met Enterprise-regels (wat een creditcard geldig maakt). En in een eenvoudige context: Het creditcard-model geeft niet om de leeftijd van de gebruiker.<\/span><\/li>\n<\/ul>\n<\/li>\n<li><strong>Entities crossing boundaries:<\/strong> <span style=\"color: #808080;\">vanwege de foutieve overtuiging dat entiteiten alle bedrijfsregels omvatten, kunnen Developers ze rechtstreeks uit controllers uitvoeren, waardoor entiteiten grenzen overschrijden waar ze dat niet zouden moeten doen.<\/span>\n<ul>\n<li><span style=\"color: #808080;\">Waarom dit fout is:<\/span><br \/>\n<strong>Breach of Separtion:<\/strong> <span style=\"color: #808080;\">het rechtstreeks aanroepen van entiteiten vanuit controllers ondermijnt het principe van Separation of Concerns.<\/span><br \/>\n<strong>Dependency Rule Violation:<\/strong> <span style=\"color: #808080;\">deze aanpak schendt de regel dat buitenste lagen afhankelijk moeten zijn van de binnenste en niet andersom.<\/span><\/li>\n<\/ul>\n<\/li>\n<li><strong>Misinterpreting Control Flow:<\/strong> <span style=\"color: #808080;\">een andere valkuil is het lezen van pijlen in het Clean Architecture diagram als control flow indicatoren in plaats van als dependencies.<\/span>\n<ul>\n<li><span style=\"color: #808080;\">Waarom dit fout is:<\/span><br \/>\n<strong>Control Flow Inversion:<\/strong> <span style=\"color: #808080;\">hoewel de afhankelijkheden naar binnen wijzen, verloopt de werkelijke controlestroom van buitenste lagen (zoals controllers) naar binnen en weer naar buiten.<\/span><br \/>\n<strong>Design Flaws:<\/strong> <span style=\"color: #808080;\">Een verkeerde interpretatie van de control flow kan leiden tot ontwerpkeuzes die de aanpasbaarheid en schaalbaarheid compromitteren.<\/span><\/li>\n<li><span style=\"color: #808080;\">Bij de incorrecte aanpak is de entiteit verweven met externe services, waardoor het systeem moeilijker te testen, begrijpen en onderhouden is. Het schendt ook het principe van dependency inversion omdat de kern entiteit nu afhankelijk is van externe details. Dit is precies het soort ontwerpfout dat Clean Architecture wil voorkomen.<\/span><\/li>\n<\/ul>\n<\/li>\n<\/ul>\n<p><span style=\"color: #808080;\">Heb je ooit het gevoel gehad verstrikt te raken in een web van code, niet wetend welk draadje je moet volgen? Clean Architecture is het kompas dat je uit het labyrint leidt. Het gaat niet om het platform &#8230; het gaat om de zuiverheid van het ontwerpen.<\/span><span style=\"color: #ff9900;\"><strong> Clean Architecture is niet zomaar een methode; het is een beweging <\/strong><\/span><span style=\"color: #808080;\">(en het roept naar ontwikkelaars zoal jullie die hongerig zijn naar duidelijkheid en uitmuntendheid).<\/span><\/p>\n<p><span style=\"color: #808080;\">Geschreven door: Ides VH.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"<p>1. What is Architecture? Layers &amp; Access: In softwareontwikkeling verwijst architectuur naar meer dan alleen hoe de code is gestructureerd of georganiseerd. Het beschrijft de choreografie van hoe verschillende lagen binnen een systeem met elkaar interactie hebben en hoe informatie door deze lagen stroomt. Wanneer je de toegang tussen deze<span class=\"more-dots\">&#8230;<\/span><\/p>\n","protected":false},"author":2,"featured_media":18718,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[214,240],"tags":[263,235,262],"class_list":["post-18706","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","category-ict","tag-clean-architecture","tag-connect-consulting","tag-ict"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.6 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\/Application<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/\" \/>\n<meta property=\"og:locale\" content=\"nl_NL\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\/Application\" \/>\n<meta property=\"og:description\" content=\"1. What is Architecture? Layers &amp; Access: In softwareontwikkeling verwijst architectuur naar meer dan alleen hoe de code is gestructureerd of georganiseerd. Het beschrijft de choreografie van hoe verschillende lagen binnen een systeem met elkaar interactie hebben en hoe informatie door deze lagen stroomt. Wanneer je de toegang tussen deze...\" \/>\n<meta property=\"og:url\" content=\"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/\" \/>\n<meta property=\"og:site_name\" content=\"Connect Consulting - ICT Careers | Infrastructure\/Application\" \/>\n<meta property=\"article:published_time\" content=\"2024-06-24T13:38:44+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2024-06-24T13:49:04+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1600\" \/>\n\t<meta property=\"og:image:height\" content=\"900\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Emilie Cambier\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Geschreven door\" \/>\n\t<meta name=\"twitter:data1\" content=\"Emilie Cambier\" \/>\n\t<meta name=\"twitter:label2\" content=\"Geschatte leestijd\" \/>\n\t<meta name=\"twitter:data2\" content=\"17 minuten\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/\"},\"author\":{\"name\":\"Emilie Cambier\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#\\\/schema\\\/person\\\/cc2cfe78fceb5d13383b490ab73ad225\"},\"headline\":\"Clean Architecture\",\"datePublished\":\"2024-06-24T13:38:44+00:00\",\"dateModified\":\"2024-06-24T13:49:04+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/\"},\"wordCount\":3066,\"publisher\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#organization\"},\"image\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2024\\\/06\\\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png\",\"keywords\":[\"Clean Architecture\",\"Connect Consulting\",\"ICT\"],\"articleSection\":[\"Blog\",\"ICT\"],\"inLanguage\":\"nl-NL\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/\",\"url\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/\",\"name\":\"Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\\\/Application\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2024\\\/06\\\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png\",\"datePublished\":\"2024-06-24T13:38:44+00:00\",\"dateModified\":\"2024-06-24T13:49:04+00:00\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#breadcrumb\"},\"inLanguage\":\"nl-NL\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"nl-NL\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#primaryimage\",\"url\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2024\\\/06\\\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png\",\"contentUrl\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2024\\\/06\\\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png\",\"width\":1600,\"height\":900},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/clean-architecture-2\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Clean Architecture\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#website\",\"url\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/\",\"name\":\"Connect Consulting - ICT Careers | Infrastructure\\\/Application\",\"description\":\"\",\"publisher\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"nl-NL\"},{\"@type\":\"Organization\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#organization\",\"name\":\"Connect Consulting - ICT Careers | Infrastructure\\\/Application\",\"url\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"nl-NL\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#\\\/schema\\\/logo\\\/image\\\/\",\"url\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2023\\\/03\\\/logo-black.png\",\"contentUrl\":\"https:\\\/\\\/connectconsulting.be\\\/wp-content\\\/uploads\\\/2023\\\/03\\\/logo-black.png\",\"width\":268,\"height\":118,\"caption\":\"Connect Consulting - ICT Careers | Infrastructure\\\/Application\"},\"image\":{\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#\\\/schema\\\/logo\\\/image\\\/\"}},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/connectconsulting.be\\\/nl\\\/#\\\/schema\\\/person\\\/cc2cfe78fceb5d13383b490ab73ad225\",\"name\":\"Emilie Cambier\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\/Application","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/","og_locale":"nl_NL","og_type":"article","og_title":"Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\/Application","og_description":"1. What is Architecture? Layers &amp; Access: In softwareontwikkeling verwijst architectuur naar meer dan alleen hoe de code is gestructureerd of georganiseerd. Het beschrijft de choreografie van hoe verschillende lagen binnen een systeem met elkaar interactie hebben en hoe informatie door deze lagen stroomt. Wanneer je de toegang tussen deze...","og_url":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/","og_site_name":"Connect Consulting - ICT Careers | Infrastructure\/Application","article_published_time":"2024-06-24T13:38:44+00:00","article_modified_time":"2024-06-24T13:49:04+00:00","og_image":[{"width":1600,"height":900,"url":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png","type":"image\/png"}],"author":"Emilie Cambier","twitter_card":"summary_large_image","twitter_misc":{"Geschreven door":"Emilie Cambier","Geschatte leestijd":"17 minuten"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#article","isPartOf":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/"},"author":{"name":"Emilie Cambier","@id":"https:\/\/connectconsulting.be\/nl\/#\/schema\/person\/cc2cfe78fceb5d13383b490ab73ad225"},"headline":"Clean Architecture","datePublished":"2024-06-24T13:38:44+00:00","dateModified":"2024-06-24T13:49:04+00:00","mainEntityOfPage":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/"},"wordCount":3066,"publisher":{"@id":"https:\/\/connectconsulting.be\/nl\/#organization"},"image":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#primaryimage"},"thumbnailUrl":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png","keywords":["Clean Architecture","Connect Consulting","ICT"],"articleSection":["Blog","ICT"],"inLanguage":"nl-NL"},{"@type":"WebPage","@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/","url":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/","name":"Clean Architecture - Connect Consulting - ICT Careers | Infrastructure\/Application","isPartOf":{"@id":"https:\/\/connectconsulting.be\/nl\/#website"},"primaryImageOfPage":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#primaryimage"},"image":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#primaryimage"},"thumbnailUrl":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png","datePublished":"2024-06-24T13:38:44+00:00","dateModified":"2024-06-24T13:49:04+00:00","breadcrumb":{"@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#breadcrumb"},"inLanguage":"nl-NL","potentialAction":[{"@type":"ReadAction","target":["https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/"]}]},{"@type":"ImageObject","inLanguage":"nl-NL","@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#primaryimage","url":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png","contentUrl":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2024\/06\/Blue-and-Grey-Tech-Professionals-IT-Consultancy-Twitter-Ad.png","width":1600,"height":900},{"@type":"BreadcrumbList","@id":"https:\/\/connectconsulting.be\/nl\/clean-architecture-2\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/connectconsulting.be\/nl\/"},{"@type":"ListItem","position":2,"name":"Clean Architecture"}]},{"@type":"WebSite","@id":"https:\/\/connectconsulting.be\/nl\/#website","url":"https:\/\/connectconsulting.be\/nl\/","name":"Connect Consulting - ICT Careers | Infrastructure\/Application","description":"","publisher":{"@id":"https:\/\/connectconsulting.be\/nl\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/connectconsulting.be\/nl\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"nl-NL"},{"@type":"Organization","@id":"https:\/\/connectconsulting.be\/nl\/#organization","name":"Connect Consulting - ICT Careers | Infrastructure\/Application","url":"https:\/\/connectconsulting.be\/nl\/","logo":{"@type":"ImageObject","inLanguage":"nl-NL","@id":"https:\/\/connectconsulting.be\/nl\/#\/schema\/logo\/image\/","url":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2023\/03\/logo-black.png","contentUrl":"https:\/\/connectconsulting.be\/wp-content\/uploads\/2023\/03\/logo-black.png","width":268,"height":118,"caption":"Connect Consulting - ICT Careers | Infrastructure\/Application"},"image":{"@id":"https:\/\/connectconsulting.be\/nl\/#\/schema\/logo\/image\/"}},{"@type":"Person","@id":"https:\/\/connectconsulting.be\/nl\/#\/schema\/person\/cc2cfe78fceb5d13383b490ab73ad225","name":"Emilie Cambier"}]}},"_links":{"self":[{"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/posts\/18706","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/comments?post=18706"}],"version-history":[{"count":9,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/posts\/18706\/revisions"}],"predecessor-version":[{"id":18717,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/posts\/18706\/revisions\/18717"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/media\/18718"}],"wp:attachment":[{"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/media?parent=18706"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/categories?post=18706"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/connectconsulting.be\/nl\/wp-json\/wp\/v2\/tags?post=18706"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}