Leestijd 7 min

Jan Eerdekens

In deze technische blogpost wil ik het hebben over hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering kunt opzetten. Waarom? Wel, ik had onlangs de gelegenheid om een klein proof of concept uit te voeren voor een klant. De klant wilde weten welke opties beschikbaar waren om interne gegevens te nemen, alle persoonlijk identificeerbare informatie (PII) te verwijderen of anonimiseren en deze op een eenvoudige manier en vorm beschikbaar te maken voor externe partijen. Na het verzamelen van verdere vereisten werd de context voor dit proof of concept als volgt gedefinieerd: Welke oplossing dan ook, het moet in staat zijn om gegevens te extraheren uit een on premise Oracle database . Het eindresultaat moet een set CSV-bestanden zijn in een Amazon S3-bucket . Tussen het ophalen van de Oracle-gegevens en het dumpen ervan in CSV-vorm op S3, moet er iets zijn dat PII-gegevens verwijdert/anonimiseert. Indien mogelijk moet de gekozen oplossing cloud native zijn. In deze 3-delige blogreeks leg ik uit hoe je eenvoudige en flexibele ETL-gebaseerde anonimisering opzet: Het onderzoek naar producten die gebruikt zouden kunnen worden om het probleem op te lossen. Controleer ook hoe geschikt ze zijn voor wat de proof of concept moet bereiken. Hoe het gekozen product gebruikt kan worden om een ETL pipeline te maken die aan de eisen voldoet. Daarnaast, hoe je een lokale Oracle database opzet in Docker die gebruikt kan worden als databron voor het data ingestion deel van het proof of concept (gewoon omdat dit zo'n PITA was om te doen). En of dit op een cloud native manier kan worden gedaan. Onderzoek Het onderzoeksdeel van het proof of concept bestaat uit 2 delen: Hoe haal je data uit een Oracle database, anonimiseer je het op de een of andere manier en sla je het op als een stel CSV bestanden in een S3 bucket aka het ETL gedeelte. Uitzoeken wat de beste manier is om de anonimisering uit te voeren. De gegevens extraheren, transformeren en opslaan Het probleem van de klant klonk meteen al opmerkelijk als iets dat je zou kunnen oplossen met een ETL-product: Extract Transform Load . Het onderzoeksgedeelte voor dit deel van het proof of concept zou zich dus concentreren op dit type product. Ik kreeg ook wat input van iemand in mijn team om eens te kijken naar singer.io , omdat dat iets was dat ze in het verleden met succes hadden gebruikt voor dit soort problemen. Als je naar de homepage van Singer kijkt, vallen een aantal dingen meteen op: Singer maakt gegevensextractie en -consolidatie mogelijk voor alle tools van je organisatie. De open-source standaard voor het schrijven van scripts die gegevens verplaatsen. Unix-geïnspireerd: Singer taps en targets zijn eenvoudige applicaties samengesteld met pipes. JSON-gebaseerd: Singer-toepassingen communiceren met JSON, waardoor ze eenvoudig te gebruiken en te implementeren zijn in elke programmeertaal. Singer is dus gewoon een specificatie, zij het geen officiële. Het is een eenvoudig, op JSON gebaseerd dataformaat en je kunt iets in dit formaat produceren (een tap in Singer terminologie) of het formaat consumeren (een target ). Je kunt deze taps en targets aan elkaar koppelen om gegevens van de ene locatie te halen en op een andere locatie op te slaan. Singer wordt standaard geleverd met een heleboel taps (meer dan 100) en targets (10). Deze taps en targets zijn geschreven in Python. Omdat het centrale punt van het systeem slechts een gegevensformaat is, is het vrij eenvoudig om er zelf een te schrijven of een bestaand formaat aan te passen. Bij het controleren van de taps zou de standaard Oracle-tap het Extract-gedeelte van ons proof of concept moeten dekken. Hetzelfde lijkt echter niet het geval te zijn voor het Load gedeelte als we kijken naar de standaard targets. Er is een CSV target , maar deze slaat de resultaten lokaal op, niet in een S3 bucket. Er is een optie om gewoon dit doel te gebruiken en de S3 upload zelf te doen nadat de ETL pijplijn is voltooid. Een andere optie zou zijn om het bestaande CSV target aan te passen en de bestandsopslag te veranderen naar S3. Even Googelen levert een door de gemeenschap gemaakt S3 CSV Singer doel op. Volgens de documentatie zou dit target precies moeten doen wat we willen. Oeps, Singer transformeert niet Met de Extract en Load delen gedekt, blijft alleen het Transform deel van de ETL pijplijn over om uit te zoeken... en dit is waar het een beetje vreemd wordt. Ook al is Singer geclassificeerd als een ETL tool, het lijkt geen ondersteuning te hebben voor het transformatie gedeelte? Toen ik hier verder naar keek, kwam ik deze onheilspellend getitelde post tegen: Why our ETL tool does not do transformations . Als ik dit lees, lijkt het erop dat ze hun JSON specificatie/gegevensformaat beschouwen als het transformatiegedeelte. Dus ze ondersteunen transformatie naar ruwe gegevens en het opslaan ervan, maar ondersteunen geen andere soorten transformaties. Dat deel mag je zelf doen nadat het ergens is opgeslagen door een Singer-doel. Het blijkt dus dat Singer meer lijkt op het EL deel van een ELT product dan op een "old school" ETL product . Op dit punt zou Singer in ieder geval voldoende moeten zijn om de gegevens uit een Oracle database te halen en in CSV-formaat in een S3 bucket te zetten. En omdat Singer vrij eenvoudig, open en uitbreidbaar is, laat ik het hier voorlopig bij. Laten we verder kijken naar de anonimiseringsopties die in deze Singer-context zouden kunnen passen. Gegevens anonimiseren Net als bij het ETL-gedeelte, kreeg ik ook voor dit gedeelte wat input die me wees op Microsoft Presidio . Op de homepage kunnen we het volgende lezen: Het biedt snelle identificatie- en anonimiseringsmodules voor privé-entiteiten in tekst en afbeeldingen , zoals creditcardnummers, namen en meer. Het faciliteert zowel volledig geautomatiseerde als semi-geautomatiseerde PII de-identificatiestromen op meerdere platforms. Aanpasbaarheid in PII-identificatie en -anonimisering. Er staan dus veel veelbelovende dingen in die me zouden kunnen helpen bij het oplossen van mijn anonimiseringsbehoeften. Bij nader onderzoek lijkt het erop dat ik dit product evalueer tijdens een grote transformatie (snap je? 😉 ) van V1 naar V2. V1 bevatte wat ETL-achtige dingen zoals het ophalen van gegevens uit bronnen (hoewel Oracle-ondersteuning in de roadmap nooit lijkt te zijn gerealiseerd ) en het opslaan van geanonimiseerde resultaten in een aantal vormen/locaties. V2 heeft deze aanpak echter volledig losgelaten en concentreert zich puur op het detecteren en vervangen van PII-gegevens. In de kern is Presidio V2 een op Python gebaseerd systeem dat bovenop een AI-model is gebouwd. Dit stelt het in staat om automatisch PII-gegevens te ontdekken in tekst en afbeeldingen en deze te vervangen volgens de regels die je definieert. Ik heb wat tests gedaan met behulp van hun online testtool en het werkt min of meer, maar voor onze specifieke context moet het zeker worden aangepast. Als we kijken naar de meegeleverde testgegevens, lijkt het erop dat het vooral eenvoudige en korte gegevens zijn, maar geen grote tekstblokken of afbeeldingen. Dit roept de vraag op: zelfs als we Presidio kunnen configureren om te doen wat we willen, slaan we misschien kleine spijkers met een grote hamer? Is Presidio te veel? Laten we hier nog eens over nadenken. Als we gemakkelijk kunnen weten en definiëren welke eenvoudige kolommen in welke tabellen moeten worden geanonimiseerd en wanneer gewoon nulling of hashing van de kolomwaarden voldoende is, dan hebben we het autodetectie deel van Presidio niet nodig. We hebben ook geen Presidio-ondersteuning nodig voor volledige tekst of afbeeldingen en we hebben ook geen fancy substitutie-ondersteuning nodig. Presidio zou een krachtige bibliotheek kunnen zijn om een automatische anonimiseringsstap te maken voor onze Singer-gebaseerde pijplijn. Het helpt ook dat Presidio gebaseerd is op Python. Maar mijn gevoel zegt dat ik misschien eerst moet proberen om een iets eenvoudigere oplossing te vinden. Ik begon te zoeken naar iets dat een eenvoudige PII-vervanging kan doen en dat werkt in een Singer tap/target context. Ik vond deze Github repository: pipelinewise-transform-field . In de documentatie staat "Transformatiecomponent tussen Singer taps en targets". Klinkt verdacht veel als het " T " deel dat Singer als een ETL miste! Verderop in de configuratiesectie lezen we zelfs: "Je moet definiëren welke kolommen door welke methode moeten worden getransformeerd en in welke conditie de transformatie moet worden toegepast." en de mogelijke transformatietypes zijn: SET-NULL : transformeert elke invoer naar NULL HASH : transformeert stringinvoer naar hash HASH-SKIP-FIRST-n : Transformeert stringinvoer naar hash waarbij de eerste n tekens worden overgeslagen, bijv. HASH-SKIP-FIRST-2 MASK-DATE : Vervangt de maand- en dagdelen van datumkolommen door 1 jan. MASK-NUMBER : Zet elke numerieke waarde om in nul. MASK-HIDDEN : verandert een willekeurige tekenreeks in 'verborgen'. Dit lijkt volledig te voldoen aan onze eenvoudige anonimiseringseisen! We kunnen zelfs zien hoe we het moeten gebruiken in de context van Singer: some-singer-tap | transform-field --config [config.json] | some-singer-target Standaard Conclusie We hebben nu alle stukjes van de puzzel voor het opzetten van eenvoudige en flexibele ETL-gebaseerde anonimisering. In de volgende blogpost laten we zien hoe ze in elkaar passen en of ze de resultaten opleveren die de klant zoekt.

Leestijd 9 min

Laurens Slechten

Bij het bouwen van producten wordt steeds meer erkend dat succes niet alleen te maken heeft met het leveren van functies of het halen van deadlines. In plaats daarvan gaat het om het leveren van echte waarde aan klanten en het bereiken van zakelijke impact. Dit vereist een mentaliteitsverandering van outputgericht naar resultaatgericht denken. In dit artikel onderzoeken we waarom het belangrijker is om uitkomsten prioriteit te geven dan output om succesvolle producten te maken en hoe je deze benadering kunt toepassen in je eigen werk. Wat betekent "uitkomsten boven output"? In de bedrijfswereld worden de termen resultaat en output vaak door elkaar gebruikt, wat voor enige verwarring zorgt. Het is echter belangrijk om het onderscheid tussen deze twee termen goed te begrijpen. Hoewel ze misschien eenvoudig lijken, laten we ze toch eens definiëren om ervoor te zorgen dat we allemaal op dezelfde golflengte zitten. Laten we ons eens voorstellen dat je je de laatste tijd uitgeput voelt, dus begin je te trainen in de sportschool om je energieker te voelen. Sommige mensen zouden kunnen zeggen dat het resultaat van je fitnessroutine het aantal uren dat je hebt gesport en de hoeveelheid gewicht die je hebt getild is. Maar het echte resultaat van je routine is veel belangrijker dan dat . Het resultaat is dat je je sterker, zelfverzekerder en gezonder voelt. Het resultaat is de manier waarop je harde werk (de output) zich heeft vertaald in een betere levenskwaliteit en een positiever zelfbeeld. Het resultaat is de manier waarop je probleem werd opgelost door de output. In een zakelijke context verwijst een resultaat naar de impact die je product heeft op de organisatie en haar klanten en belanghebbenden, terwijl een output verwijst naar de tastbare dingen die je (ontwikkel)team produceert, zoals documenten, software en tests. Focussen op resultaat boven output betekent succes definiëren op basis van het bereiken van een specifiek resultaat en vooruitgang meten op basis van hoe dicht je bij het bereiken van dat resultaat bent. Het doel van je team is niet om output te produceren; het is om een specifiek resultaat te bereiken. Een succesvol team streeft ernaar het gewenste resultaat te maximaliseren en tegelijkertijd de hoeveelheid geproduceerd werk te minimaliseren. De voordelen van een resultaatgerichte aanpak 1. Het helpt je te ontsnappen aan de bouwval Het eerste Agile Principe stelt dat je topprioriteit is om je klanten gelukkig te maken door waardevolle software zo vroeg en consistent mogelijk op te leveren. Naarmate agile werkwijzen op verschillende gebieden worden toegepast, hebben mensen dit principe geherformuleerd om het belang van het snel en consistent leveren van waarde aan klanten te benadrukken. Als je succes meet op basis van een resultaatgerichte metriek, zoals " het aantal doorkliks op nieuwsbrieven binnen zes maanden met 15% verhogen ", koppel je de inspanningen van je team onmiddellijk aan de waarde voor je organisatie en klanten. Dit helpt je te begrijpen welke impact je maakt en wanneer je echt een verschil maakt. Als je daarentegen succes meet door alleen te kijken naar de dingen die je produceert, zoals " het aantal opgeleverde features " of " het aantal voltooide punten in een scrum sprint ", loop je het risico in wat Melissa Perri (product management expert, spreker en auteur) "de bouwval" noemt. Deze valkuil houdt in dat je je alleen richt op het maken van features zonder rekening te houden met de gewenste resultaten. Wanneer organisaties prioriteit geven aan output boven uitkomsten, lopen ze het risico verstrikt te raken in een cyclus van het bouwen van meer en meer features zonder echt te begrijpen of ze klantproblemen oplossen of bedrijfswaarde creëren. Door je te fixeren op het opleveren van features als maatstaf voor succes, kun je het grotere geheel uit het oog verliezen. Het vertelt je niet of je de juiste dingen bouwt. Het is dus essentieel om je focus te verleggen naar de resultaten die er toe doen. Dit vereist een mentaliteitsverandering die de behoeften en gewenste resultaten van de klant op de voorgrond plaatst. Door succes te definiëren op basis van resultaten, kan je team ontsnappen aan de bouwval . 2. Het helpt je te focussen op leren en itereren Als je kritisch gaat denken over het leveren van waarde in plaats van features, loop je al snel tegen het probleem aan waar ik het eerder over had: hoe weet je zeker dat de features die je bouwt ook echt waarde gaan leveren? Een resultaatgerichte aanpak erkent dat je misschien niet vanaf het begin alle antwoorden hebt en dat leren een belangrijk onderdeel van het proces is. Daarom heb je bij het werken met uitkomsten een hulpmiddel nodig: het experiment. Wanneer je resultaatgericht denken combineert met een proces dat gebaseerd is op het uitvoeren van experimenten, begin je echt het ware potentieel van agile benaderingen te ontsluiten. Dit is vooral waardevol in situaties waar veel onzekerheid is. Als je bijvoorbeeld een nieuw softwareproduct maakt, weet je misschien niet zeker of het de gewenste impact zal hebben op je bedrijf en of alle mooie functies die je hebt bedacht wel nodig zijn. Door te focussen op resultaten, kun je doelen stellen die je team toelaten om te experimenteren en verschillende oplossingen uit te proberen tot ze vinden wat het beste werkt. In een agile context behandelen we elke stap als een hypothese en een experiment gericht op het bereiken van een specifiek resultaat. Dit is waar het concept van een MVP, of Minimum Viable Product , om de hoek komt kijken. Beschouw MVP als het kleinste ding dat je kunt doen of het kleinste ding dat je kunt bouwen om te leren of je hypothese juist is. Dit iteratieve proces van testen, leren en aanpassen stelt teams in staat om te experimenteren, om verschillende oplossingen uit te proberen, totdat ze de oplossing vinden die werkt. 3. Het helpt je team meer autonomie te bereiken Werknemers vinden het vaak een uitdaging om een diep gevoel van doelgerichtheid en motivatie te ervaren, enkel door de output die ze produceren. Wat mensen echt drijft om elke dag op het werk te verschijnen, zijn niet de specifieke taken waarmee ze zich elke dag bezighouden, maar eerder de betekenisvolle resultaten waar hun werk uiteindelijk aan zal bijdragen . De nadruk op resultaten helpt om je team op één lijn te krijgen rond een gemeenschappelijk doel en gedeelde doelen. Door duidelijkheid te verschaffen over wat er bereikt moet worden, kun je je team motiveren en in staat stellen om samen te werken aan duidelijke doelen die het product moet bereiken. Hierdoor kan je team prioriteiten stellen in hun werk en functies bouwen die bijdragen aan het bereiken van die doelen. Door hen beslissingen te laten nemen over de functies die ze bouwen, krijgen ze een groter gevoel van eigenaarschap over het werk dat ze doen. De resultaten voor je product definiëren en implementeren Nu ben je het er misschien wel mee eens dat focussen op resultaten klinkt als een goed idee, maar ze daadwerkelijk implementeren in onze bedrijfspraktijken is niet zo eenvoudig . Elke methodologie heeft zijn nadelen. Eén uitdaging is dat uitkomsten minder gemakkelijk te meten en te kwantificeren zijn dan outputs. Ten tweede staan veel bedrijven onder druk om snel door te gaan naar het volgende project als het ene is afgerond . Helaas wordt het iteratieve proces van testen, leren en aanpassen nog steeds niet vaak toegepast. Tot slot, wat het moeilijk maakt, is dat we vaak doelen stellen die te hoog gegrepen zijn . Als je het team bijvoorbeeld vraagt om het bedrijf winstgevender te maken of de risico's te verminderen, dan is dat te complex omdat die uitdagingen bestaan uit veel variabelen om te beïnvloeden. Deze doelen op impactniveau zijn te complex voor teams. In plaats daarvan moet je je richten op kleinere en beter beheersbare doelen . Om dit te doen, moet je je team vragen om zich te concentreren op het veranderen van klantgedrag op manieren die positieve bedrijfsresultaten opleveren. In zijn boek "Outcomes Over Output: Why Customer Behavior Is The Key Metric For Business Success" presenteert Joshua Seiden drie magische vragen die je kunnen helpen bij het identificeren van geschikte resultaten: Wat zijn de gedragingen van gebruikers en klanten die bedrijfsresultaten genereren? (Dit is het resultaat dat je probeert te creëren.) Hoe kunnen we mensen meer van dat gedrag laten vertonen? (Dit zijn de functies, beleidswijzigingen, etc. die je gaat doen om te proberen de resultaten te creëren). Hoe weten we of we gelijk hebben? (Dit onthult de experimenten en statistieken die je zult gebruiken om de voortgang te meten). Ik zal je een voorbeeld geven van hoe dit werkt. Stel je voor dat je een e-commerce kledingwinkel runt en je hebt te maken met zware concurrentie van een concurrerend bedrijf. Je doel is om de klantloyaliteit te verbeteren, dus stel je het team een breed doel om de frequentie van klantbezoeken te verhogen van één keer per maand naar twee keer per maand. Om dit effect te bereiken, moet u specifiek gedrag van klanten identificeren dat correleert met het bezoeken van uw site. U merkt bijvoorbeeld dat klanten de neiging hebben om de site te bezoeken na het openen van de maandelijkse nieuwsbrief waarin nieuwe artikelen worden gepresenteerd. Daarom zou een mogelijke uitkomst kunnen zijn om de doorklikratio van de nieuwsbrief te verhogen. Daarnaast merkt u dat klanten de site ook bezoeken nadat een vriend een afbeelding van een van de artikelen heeft gedeeld op sociale media. Een andere mogelijke uitkomst is dus om klanten aan te moedigen vaker afbeeldingen van artikelen te delen. Door je te richten op deze klantgedragingen die het gewenste resultaat van sitebezoeken bepalen, zorg je ervoor dat je doelen zowel observeerbaar als meetbaar zijn. Dit is cruciaal omdat je zo de voortgang effectief kunt beheren en bijhouden. Ik hoop dat dit voorbeeld duidelijk maakt hoe resultaten specifiek kunnen zijn en gemakkelijk kunnen worden uitgesplitst. Onthoud dat een resultaat een gedrag is dat klanten vertonen en dat direct van invloed is op de bedrijfsresultaten. Door dit gedrag te begrijpen, kunt u uw inspanningen afstemmen op de resultaten die echt belangrijk zijn voor uw bedrijf. Aanknopingspunten Een resultaat verwijst naar de impact die je product heeft op de organisatie en haar klanten en belanghebbenden, terwijl een output verwijst naar de tastbare dingen die je team produceert, zoals documenten, software en tests. Het doel van je team is niet om output te produceren; het is om een specifieke uitkomst te bereiken. Een succesvol team streeft ernaar om het gewenste resultaat te maximaliseren en tegelijkertijd de hoeveelheid geproduceerd werk te minimaliseren. Door je te fixeren op feature delivery als maatstaf voor succes, kun je het grotere geheel uit het oog verliezen. Het vertelt je niet of je de juiste dingen bouwt. Het is dus essentieel om je focus te verleggen naar de resultaten. Een resultaatgerichte aanpak erkent dat je misschien niet meteen alle antwoorden hebt en dat leren een belangrijk onderdeel is van het proces. Daarom heb je bij het werken met uitkomsten een hulpmiddel nodig: het experiment. Als je je werk plant, wees dan duidelijk over je aannames. Wees bereid om je veronderstellingen te testen door je werk uit te drukken als hypotheses. Test je hypotheses voortdurend door in kleine iteraties te werken, te experimenteren en te reageren op de gegevens en feedback die je verzamelt. Verwar impact - ambitieuze doelen op hoog niveau - niet met uitkomsten. Impact is belangrijk, maar deze doelen zijn te complex voor teams omdat ze bestaan uit veel variabelen om te beïnvloeden. Gebruik deze vragen om resultaten te definiëren: wat zijn de menselijke gedragingen die bedrijfsresultaten stimuleren? Hoe kunnen we mensen meer van deze dingen laten doen? Hoe weten we of we gelijk hebben? 👀 Meer weten over onze diensten ? Klik hier om meer te weten te komen!

Leestijd 6 min

Christophe Senesael

Mobiele ontwikkeling is tegenwoordig veel complexer en functioneler dan tien jaar geleden. Wat ooit begon als eenvoudige projecten met een paar functies zijn nu geëvolueerd tot geavanceerde systemen met alles van biometrische authenticatie en AI tot geavanceerde camera-integraties. Deze groei vereist een architectuurstrategie die de complexiteit effectief beheert met behoud van codebases van hoge kwaliteit. In dit artikel verkennen we een robuuste architecturale oplossing voor deze uitdaging: een modulaire of samenstelbare architectuur in mobiele ontwikkeling, geïnspireerd op de microservicearchitectuur die gangbaar is in backendontwikkeling. Wat is een modulaire architectuur? Net als bij microservices splitsen we een grote applicatie op in kleine, gerichte mobiele bibliotheken, die zich elk richten op een specifiek domein of een specifieke functionaliteit. Deze modulaire architectuur maakt het mogelijk om meerdere applicaties te bouwen met behulp van deze herbruikbare componenten, waarbij ervoor wordt gezorgd dat elke module losjes gekoppeld blijft. Dit maximaliseert de flexibiliteit, testbaarheid en aanpasbaarheid van elke component. Laten we eens dieper ingaan op de voordelen van een modulaire architectuur bij mobiele ontwikkeling. Waarom een modulaire architectuur gebruiken bij mobiele ontwikkeling? Separation of Concern afdwingen met een modulaire architectuur Het gebruik van een modulaire architectuur bij mobiele ontwikkeling zorgt voor een duidelijke scheiding van zorgen. Dit gaat verder dan de onderliggende code tot de organisatiestructuur van het project. Elke module functioneert als een op zichzelf staande eenheid, die een afzonderlijk verantwoordelijkheidsdomein vertegenwoordigt en afzonderlijk wordt ontwikkeld en onderhouden. Dit verbetert niet alleen de leesbaarheid en beheersbaarheid van het project, maar stroomlijnt ook de samenwerking en het debuggen. Bijgevolg creëert de ontwerpfilosofie van de modulaire architectuur een samenhangend systeem waarin de grenzen van de componenten onmiddellijk duidelijk zijn, zelfs zonder in de codebase te duiken. Modulaire architectuur bevordert herbruikbaarheid en onderhoudbaarheid van code Een modulaire architectuur verduidelijkt de projectstructuur en bevordert de herbruikbaarheid en onderhoudbaarheid van de code aanzienlijk. Door de app op te delen in modules creëren we herbruikbare componenten die kunnen worden geïntegreerd in verschillende delen van de applicatie of zelfs in geheel nieuwe projecten. Dit hergebruik van code minimaliseert overbodig werk, waardoor ontwikkelaars zich kunnen richten op innovatie in plaats van het wiel opnieuw uit te vinden voor elke nieuwe functie. Bovendien vereenvoudigt een modulaire architectuur het onderhoud en updaten van apps. Modules werken onafhankelijk van elkaar, waardoor verbeteringen of fixes op de ene module kunnen worden toegepast zonder andere modules onbedoeld te verstoren. Deze scheiding vereenvoudigt het testen en maakt gerichte validatie van wijzigingen mogelijk, wat zorgt voor een stabielere en betrouwbaardere applicatie. Het resultaat is dat de modulaire aanpak een codebase oplevert die niet alleen robuuster is, maar ook flexibeler, zodat de app zich snel kan aanpassen aan nieuwe vereisten of technologische vooruitgang. Modulaire architectuur verbetert testbaarheid Een van de grootste voordelen van een modulaire architectuur in grote mobiele ontwikkelingsprojecten is de verbeterde testbaarheid. In grote monolithische mobiele projecten kunnen bouwtijden aanzienlijk zijn, wat vaak resulteert in inefficiënte workflows. Stel je bijvoorbeeld voor dat je werkt aan een grote Xamarin-applicatie zonder hot reload-mogelijkheid. Als de UI zich misdraagt, moet je de hele applicatie bouwen en de hele flow doorlopen. En als deze flow afhankelijk is van web calls die worden onderhouden door een klantenteam, dan weet je dat je te maken hebt met een ongelooflijk tijdrovend en inefficiënt proces. Voordelen van modulaire architectuur bij mobiel testen Het gebruik van een modulaire architectuur voor je mobiele ontwikkelingsprojecten biedt een reeks belangrijke voordelen op het gebied van testen: Geïsoleerd testen Met een modulaire architectuur kun je alle gegevensafhankelijkheden van een module mocken en deze testen als een op zichzelf staande app. Deze isolatie maakt het mogelijk om gericht te testen op specifieke functionaliteiten zonder de overhead van het draaien van de hele applicatie. Kortere bouwtijden Het bouwen van de hele applicatie voor elke wijziging is niet nodig, waardoor de end-to-end testtijden aanzienlijk worden verkort. Deze efficiëntie leidt tot snellere ontwikkelcycli en snellere iteratie, cruciaal voor het behouden van een hoge productiviteit. Stabiele testomgeving Het ontkoppelen van modules minimaliseert het risico dat de ene component de andere beïnvloedt, wat zorgt voor betrouwbaardere tests en eenvoudiger opsporen van bugs. Parallel ontwikkelen en testen Teams kunnen verschillende modules gelijktijdig ontwikkelen en testen zonder te wachten tot een gedeelde codebase gestabiliseerd is, waardoor het ontwikkelproces versnelt en dynamische, flexibele workflows mogelijk worden. Een modulaire architectuur resulteert in een efficiënter, betrouwbaarder en schaalbaarder mobiel ontwikkelproces en beperkt de risico's van monolithische architecturen. Door te focussen op modulariteit verbeteren we zowel de ontwikkelings- als de testfase, wat leidt tot een betere algehele softwarekwaliteit. Modules definiëren bij mobiele ontwikkeling Bij het ontwikkelen van applicatiemodules is samenwerking met domeinexperts cruciaal om de verschillende functies binnen een organisatie volledig te begrijpen. Door deze samenwerking wordt duidelijk hoe de applicatie logisch kan worden gesegmenteerd. Het documenteren van rollen, gekoppeld aan domeinspecifieke vereisten, moet worden opgelost als een iteratief proces, waarbij voortdurende verfijningen mogelijk zijn die zijn afgestemd op de veranderende behoeften van de organisatie. De basismodule In onze modulaire architectuur gebruiken we een basismodule. Zie dit als de genetische code van de applicatie - de kern waarvan elke andere module erft. Deze basismodule bevat alle gedeelde, domeinagnostische functies, waaronder universele ontwerpelementen en besturingselementen. Het centraliseren van deze gemeenschappelijke aspecten zorgt voor een consistente look en feel in de hele app. Elke gespecialiseerde module die op deze basis is gebouwd, neemt inherent deze gedeelde kenmerken over, waardoor de ontwikkeling wordt gestroomlijnd en ervoor wordt gezorgd dat wijzigingen aan fundamentele aspecten slechts eenmaal hoeven te worden doorgevoerd, wat doorwerkt in de hele applicatie. Onze eerste module maken Zodra de basismodule klaar is, is de volgende stap het maken van de eerste samenstelbare module. De structuur bootst de klassieke gelaagde architectuur na (Data, Domain en Presentation projecten), met een extra Test project om het testen van de module te vergemakkelijken. Dit Test-project roept de module rechtstreeks aan. Het is een eenvoudige mobiele toepassing, meestal bestaande uit een knop om de component op te starten. De rol is om mock definities te bieden voor alle vereiste afhankelijkheden van de module, zodat deze kan worden ingezet op een apparaat of emulator om te testen. Projectstructuur voor modulaire architectuur Gegevensproject: Definieert gegevensentiteiten en vereiste gegevensinterfaces. Domeinproject: Bevat kernbedrijfslogica en domeinmodellen. Definieert use cases en bedrijfsregels die op de gegevens werken. Presentatie Project: Beheert UI-componenten en presentatielogica. Bevat views en UI-gerelateerde hulpprogramma's. Test Project: Standalone project dat rechtstreeks met de module interageert. Biedt schijnimplementaties voor afhankelijkheden. Maakt geïsoleerd testen van de functionaliteit van de module mogelijk. Gegevensafhankelijkheden definiëren in een modulaire architectuur Voor elke samenstelbare bibliotheek is het van cruciaal belang om gegevensafhankelijkheden te definiëren via contracten (bv. interfaces) in plaats van gegevensbronnen hard te coderen. Dit zorgt ervoor dat de bibliotheek agnostisch blijft wat betreft de herkomst van gegevens, of ze nu afkomstig zijn van een lokale database of een web-API. Dependency injection levert de juiste gegevensimplementaties aan de module. Met deze aanpak kunnen consumenten de gegevensbron kiezen. Door ervoor te zorgen dat de samenstelbare bibliotheek zich alleen bezighoudt met het type gegevens dat nodig is, in plaats van met de herkomst van de gegevens, wordt het mocken van gegevenscontracten en de emulatie van verwachte functionele scenario's vereenvoudigd. Deze modulaire en testbare aanpak verbetert de flexibiliteit en onderhoudbaarheid van de codebase aanzienlijk. Een module of component gebruiken in mobiele ontwikkeling Het integreren van een ontwikkelde module in je applicatie is eenvoudig dankzij duidelijk gedefinieerde interfaces en afhankelijkheden: Importeer de module: Neem de module op in je project. Dit houdt vaak in dat je een afhankelijkheid toevoegt aan de buildconfiguratie van je project. Afhankelijkheden injecteren: Gebruik injectie van afhankelijkheden om de nodige gegevensbronnen en services te leveren die de module nodig heeft. Dit houdt de component agnostisch over de oorsprong van zijn gegevens, wat flexibiliteit en herbruikbaarheid bevordert. De module initialiseren: Stel alle initiële configuraties of toestanden in die nodig zijn voor de module, zoals initiële gegevens of specifieke instellingen. De API van de module gebruiken: Communiceer met de module via de openbare API, meestal inclusief methoden om flows te starten die gegevens retourneren of weergaven integreren met uw applicatie. Conclusie: de toekomst van mobiele ontwikkeling ligt in modulaire architectuur Het omarmen van modulaire architectuur in mobiele ontwikkeling biedt talloze voordelen, die zowel het ontwikkelproces als het eindproduct verbeteren. Door applicaties op te splitsen in kleinere, beheersbare componenten dwingen we scheiding van zorgen af, bevorderen we herbruikbaarheid van code en verbeteren we de onderhoudbaarheid aanzienlijk. Modules maken geïsoleerd testen mogelijk, verkorten bouwtijden en creëren een stabiele testomgeving, wat uiteindelijk leidt tot een efficiëntere en betrouwbaardere ontwikkelworkflow.