Architectuurpatronen
Lees meer over Goed Ontworpen resource- en kostenoptimalisatie → Uw optimaliseringsverantwoordelijkheden
Deze pagina biedt uitgebreide patroonrichtlijnen voor architectonische problemen, waaronder functionele eenheden, scheiding van problemen, statusbeheer, API-beheer en berichtenverkeer. Deze patronen bepalen het succes van oplossingen op de lange termijn door weloverwogen ontwerpbeslissingen over servicegrenzen, gegevenstoegangspatronen en componentverantwoordelijkheden.
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Apex klassen | ✅ Serviceklassen volgen het principe van enkelvoudige verantwoordelijkheid met namen die duidelijk het doel aangeven (AccountService, OrderProcessor, InventoryManager). Elke serviceklasse richt zich op één domein of bedrijfsmogelijkheid. Methoden binnen serviceklassen hebben enkelvoudige, gerichte verantwoordelijkheden onder 20 regels. |
| Triggers | ✅ Triggers delegeren aan handlerklassen in plaats van direct bedrijfslogica te bevatten. Triggerhandlerpatroon dat consistent wordt gebruikt met duidelijke methodenamen op context (handleBeforeInsert, handleAfterUpdate). Handlerklassen organiseren logica op triggerevent met enkelvoudige verantwoordelijkheden per methode. |
| Lightning webcomponenten | ✅ De componenten volgen enig verantwoordelijkheidsprincipe met duidelijke steuninterfaces voor configuratie. Elke LWC richt zich op één UI-probleem (gegevensweergave, gebruikersinvoer, navigatie). Componenten die zijn ontworpen voor compositie, niet voor monolithische implementaties. |
| Servicelaag | ✅ Serviceklassen omvatten bedrijfslogica onafhankelijk van invoerpunt (trigger, API, stroom, batch). Dezelfde serviceklasse verwerkt meerdere aanroepcontexten zonder duplicatie. Servicelaag scheidt bedrijfsregels van zorgen over presentatie en gegevenstoegang. |
| Herbruikbare componenten | ✅ Componenten ontworpen voor hergebruik binnen meerdere projecten en teams. Configuratiegestuurde werking met behulp van typen aangepaste metagegevens maakt gedragswijzigingen mogelijk zonder code-implementatie. Aanroepbare acties maken Apex logica zichtbaar als declaratieve bouwstenen die kunnen worden gebruikt vanuit Flow en externe doeltreffende combinaties. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Godsklasse | ⚠️ Vermijd het accumuleren van buitensporige verantwoordelijkheid in één klasse. Splits grote klassen (> 500 regels) op in gerichte klassen met enkelvoudige verantwoordelijkheden. Reorganiseer klassen wanneer ze meerdere niet-gerelateerde problemen afhandelen (OrderProcessor moet niet ook e-mailverzending en rapportage afhandelen). |
| Gemengde bezorgdheid | ⚠️ Vermijd het mengen van triggerlogica, bedrijfsregels en gegevenstoegang in afzonderlijke klassen. Scheid presentatielogica van bedrijfslogica in controllers. Houd integratieproblemen gescheiden van kerndomeinlogica. |
| Triggerlogica in triggers | ⚠️ Vermijd het rechtstreeks inbedden van bedrijfslogica in triggerbestanden. Gebruik nooit meer dan 300 regeltriggers met geneste voorwaarden. Delegeer altijd aan handlerklassen met een duidelijke indeling van methoden op triggercontext. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Bedrijfslogica | ✅ Bedrijfsregels gecentraliseerd in serviceklassen, niet verspreid over triggers, controllers en batchklassen. Domeinklassen omvatten consistent gedrag op recordniveau (validatie, standaardwaarden, afgeleide waarden), ongeacht de manier waarop records het systeem binnenkomen. Logica wordt hergebruikt via de servicelaag in plaats van gedupliceerd via invoerpunten. |
| Gegevenstoegang | ✅ Gegevenstoegang geabstraheerd achter repository of selector patroonklassen. SOQL-query’s die zijn gecentraliseerd in selectorklassen (AccountSelector, OpportunitySelector), zorgen voor consistente veldlijsten en WHERE-clausules. Een opslagplaatspatroon maakt testen met nepgegevensbronnen mogelijk zonder de bedrijfslogica te wijzigen. |
| Interfacecontracten | ✅ Componenten communiceren via expliciete interfaces in plaats van implementatiedetails. Apex interfaces definiëren contracten tussen lagen. Configuratie van aangepaste metagegevens definieert gedragsgrenzen. Platform-events bieden berichtenverkeerscontracten tussen producenten en consumenten. |
| Modulegrenzen | ✅ Gebonden contexten definiëren duidelijke eigendomsgrenzen voor gegevensmodellen en bedrijfsregels. Elke module is eigenaar van zijn gegevens, automatisering en bedrijfslogica. Modules werken samen via gedefinieerde API’s in plaats van databaseobjecten rechtstreeks te delen. Documentatie geeft duidelijk aan welk team eigenaar is van welke objecten en services. |
| Afhankelijkheidsstroom | ✅ Afhankelijkheden stromen in één richting (presentatie → zaken → gegevens). Kernbedrijfslogica is afhankelijk van niets externs, waardoor onafhankelijke evolutie mogelijk wordt. Infrastructuurproblemen (logging, caching, externe API’s) zijn afhankelijk van bedrijfslogica via interfaces, niet omgekeerd. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Logische duplicatie | ⚠️ Vermijd het dupliceren van bedrijfslogica over triggers, API-eindpunten en batchklassen. Centraliseer in de servicelaag en hergebruik deze voor alle invoerpunten. Telkens wanneer dezelfde bedrijfsregel in meerdere klassen wordt weergegeven, extraheert u deze naar gedeelde service. |
| Gegevenstoegang verspreid | ⚠️ Vermijd SOQL-query’s die zijn verspreid over trigger-, controller- en batchklassen met inconsistente veldlijsten en WHERE-clausules. Centraliseer query’s in selectorklassen om consistente patronen te garanderen en LDV-optimalisering op één locatie in te schakelen. |
| Bedrijfslogica in triggers | ⚠️ Vermijd validatieregels, veldberekeningen en werkstroomcombinaties die rechtstreeks in triggercode zijn ingebed. Ga naar serviceklassen of domeinklassen. Houd triggers dun en richt u alleen op delegeren aan de juiste handlers. |
| Bedrijfslogica in controllers | ⚠️ Vermijd complexe berekeningen, validatie of gegevensmanipulatie in Aura/LWC-controllermethoden. Controllers moeten aanroepen naar de servicelaag orkestreren, niet rechtstreeks bedrijfsregels implementeren. |
| Circulaire afhankelijkheden | ⚠️ Vermijd pakketten of klassen met cirkelvormige afhankelijkheden waarbij A afhankelijk is van B en B afhankelijk is van A. Los dit op door gedeelde zorgen te extraheren in afzonderlijke module, afhankelijkheidsrichting om te keren of eventgestuurde communicatie te gebruiken om de koppeling te verbreken. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Platformcachegeheugen (organisatiepartitie) | ✅ Vaak geopende verwijzingsgegevens in het cachegeheugen van de organisatiepartitie, waaronder opzoekopdrachten van aangepaste metagegevens, keuzelijstwaarden, configuratie-instellingen en berekende resultaten van dure bewerkingen. Standaard TTL geconfigureerd op basis van gegevensvolatiliteit (uren voor maandelijks veranderende referentiegegevens, minuten voor vaak bijgewerkte configuratie). De sleutelstrategie voor het cachegeheugen voorkomt botsingen tussen verschillende gegevenstypen. |
| Platformcachegeheugen (sessiepartitie) | ✅ Gebruikersspecifieke voorkeuren, berekende personalisatiegegevens en status van sessiebereik opgeslagen in sessiecache. Sessiecachegeheugen niet gebruikt voor gegevens die moeten worden gedeeld tussen gebruikers. Cache-invaliditeitsstrategie handelt updates van gebruikersvoorkeuren op de juiste manier af. |
| Lightning Data Service | ✅ LDS biedt automatische client-side record caching voor Lightning webcomponenten. Standaard CRUD bewerkingen gebruiken LDS in plaats van aangepaste Apex controllers. LDS elimineert redundante server round-trips en biedt optimistische UI-updates. Componenten maken gebruik van gedeelde LDS-cachegeheugen over de hele pagina. |
| Aangepaste metagegevenstypen | ✅ Configuratie- en gedragsregels opgeslagen in aangepaste metagegevenstypen in plaats van hardcoded in klassen. Aangepaste metagegevens die in omgevingen kunnen worden geïmplementeerd via wijzigingssets of brongestuurde ontwikkeling. Wijzigingen in aangepaste metagegevens vereisen geen volledige implementatiecyclus. Cache aangepaste metagegevensquery’s in Platformcachegeheugen voor prestaties. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Query in lus | ⚠️ Vermijd het uitvoeren van SOQL binnen herhalingslussen. Voer een query uit op alle benodigde records in één SOQL-instructie buiten lussen. Orden resultaten in Kaarten op bovenliggende ID voor opzoeken tijdens herhaling. Dit is het meest voorkomende Salesforce-antipatroon. |
| Repetitieve query’s | ⚠️ Vermijd het meerdere malen per transactie opvragen van dezelfde aangepaste metagegevens, aangepaste instellingen of verwijzingsgegevens. Eén query uitvoeren, cachegeheugen in platformcachegeheugen of statische transactievariabele, hergebruiken binnen transactie. |
| Ontbrekende cachestrategie | ⚠️ Vermijd het herhaaldelijk uitvoeren van query’s op vaak gebruikte verwijzingsgegevens zonder caching. Implementeer Platformcachegeheugen voor aangepaste metagegevens, configuratie en berekende resultaten. Definieer de juiste TTL op basis van gegevensvolatiliteit. |
| Cache zonder validatie | ⚠️ Vermijd caching van gegevens zonder rekening te houden met een ongeldige strategie. Definieer cache-TTL die geschikt is voor de updatefrequentie. Implementeer handmatig wissen van cachegeheugen wanneer brongegevens worden gewijzigd als TTL alleen onvoldoende is. |
| Status van onbeheerde sessie | ⚠️ Vermijd het aannemen van sessiestatus blijft bestaan over paginanavigaties zonder verificatie. Lightning componenten moeten statusvernieuwing afhandelen bij het laden van de pagina. Gebruik Lightning Data Service voor automatische statussynchronisatie. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Architectuurplanning voor oplossingen | ✅ Architectuurplanning vindt plaats vóór een aanzienlijke investering in bouwen, waaronder een analyse van de vereisten (functioneel en niet-functioneel), een analyse van beheerlimieten voor verwachte gegevensvolumes, patroonselectie die is afgestemd op de vereisten, en componentontwerp dat de belangrijkste componenten en interfaces definieert. |
| Selectie van ontwerppatroon | ✅ Bewezen Salesforce-ontwerppatronen consistent toegepast: Servicelaagpatroon voor hergebruik van bedrijfslogica, Patroon van opslagplaats/selector voor abstractie van gegevenstoegang, Strategiepatroon voor verwisselbare algoritmen, Domeinpatroon voor werking op recordniveau, Triggerhandlerpatroon voor consistente triggerorganisatie. |
| Architectuurbeslissingsrecords | ✅ Belangrijke architectonische beslissingen gedocumenteerd in ADR’s opgeslagen in versiebeheer. Bijwerkingen leggen de context vast (bedrijfsfactoren, technische beperkingen), de beslissing (waarvoor is gekozen), de alternatieven (waarom zijn andere afgewezen) en de gevolgen (afwegingen, technische schulden, triggers voor een nieuw bezoek). |
| Evaluatie samenstellen versus kopen | ✅ AppExchange evaluatie voorafgaat aan aangepaste ontwikkelingsbeslissingen met behulp van total cost of ownership analyse. Evaluatiecriteria omvatten strategische waarde (concurrentieverschil versus commodity), TCO-vergelijking (bouwinspanning, onderhoud, upgradekosten), integratiecomplexiteit en exitkosten als de oplossing niet voldoet. |
| Analyse van gouverneurslimiet | ✅ Architectonische planning identificeert welke regisseur de meeste ontwerpbeperkingen beperkt op basis van verwachte gegevensvolumes en transactiepatronen. Transacties die zijn ontworpen om onder piekomstandigheden minder dan 80% van één beheerlimiet te verbruiken. Marge die is samengesteld voor groei, toekomstige voorzieningen en onverwachte gebruikspatronen. |
| Risicobeoordeling | ✅ Technische risico’s geïdentificeerd voor architectonische benaderingen die platformgrenzen verleggen. Beperkte strategieën gedefinieerd voor elk significant risico. Prototype- of proof-of-concept-werk valideert aannames voor technische benaderingen met hoog risico vóór de volledige belofte voor het samenstellen. |
Anti-patronen
| Waar te zoeken | Hoe slecht eruitziet |
|---|---|
| Geen planning | ⚠️ Begin niet met samenstellen zonder gegevensvolumes, implicaties van beheerlimieten of patroonselectie te analyseren. Workshop Architectuurplanning moet de belangrijkste beperkingen identificeren, patronen selecteren en valideren op basis van beheerlimieten voordat het samenstellen begint. |
| Niet-gedocumenteerde beslissingen | ⚠️ Vermijd architectonische beslissingen die worden genomen in vergaderingen zonder context, motivering, alternatieven en gevolgen vast te leggen. Gebruik Architectuurbeslissingsrecords die zijn opgeslagen in versiebeheer, waarbij de beslissingscontext voor toekomstige teamleden behouden blijft. |
| Analyse Geen samenstelling versus koop | ⚠️ Vermijd het samenstellen van aangepaste oplossingen zonder AppExchange evaluatie. Evalueer de beste 3-5 relevante pakketten vóór aangepaste ontwikkeling. Vergelijk TCO inclusief implementatie-inspanning, onderhoud, upgradekosten en exitkosten. |
| Onder-engineering | ⚠️ Vermijd ontwerpen alleen voor huidige gegevensvolumes zonder groeiprojectie. Prognosegegevensgroei over 2-3 jaar. Ontwerp querypatronen met selectiviteit gevalideerd op basis van 5-10x huidige volumes. Bouw architectonische marge voor groei. |
Patronen
| Waar te zoeken | Hoe goed eruitziet |
|---|---|
| Beheerde pakketten van de tweede generatie (2GP) | ✅ 2GP gebruikt voor nieuwe beheerde pakketten die naamruimte isolatie, AppExchange distributie en IP-bescherming vereisen. Brongestuurde ontwikkelingswerkstroom met modulaire toepassingsontwikkeling. Pakketafhankelijkheden expliciet beheerd. Versies die zijn uitgebracht met semantische versiebeheer. |
| Ontgrendelde pakketten | ✅ Ontgrendelde pakketten die worden gebruikt voor interne ondernemingstoepassingen die modulariteit vereisen zonder naamruimtebeperkingen. Onafhankelijke implementatie van pakketten zonder organisatieafhankelijke artefacten. Pakketafhankelijkheden bijgehouden voor de juiste volgorde van implementatie. Versiestrategie gedefinieerd voor interne pakketten. |
| Modulegrenzen | ✅ Duidelijke eigendom grenzen gedefinieerd voor elk pakket. Elk pakket is eigenaar van zijn gegevensmodel, bedrijfsregels en automatisering. Pakketten hebben interactie via gedefinieerde interfaces in plaats van directe objecttoegang. Documentatie identificeert eigendom van pakketten en contracten tussen pakketten. |