Arkkitehtuurikuviot
Lue lisää hyvin rakennetuista resurssien ja kustannusten optimoinnista → optimointivastuut
Tämä sivu tarjoaa kattavan kuvion ohjeita arkkitehtuurin huolenaiheisiin, mukaan lukien toiminnallisiin yksiköihin, huolenaiheiden erottamiseen, osavaltioiden hallintaan, API-hallintaan ja viesteihin. Nämä kuviot määrittävät ratkaisun pitkän aikavälin onnistumisen suunnittelun päätöksillä, jotka koskevat palvelurajoja, datan käyttöoikeuskuvioita ja komponenttien vastuuta.
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Apex-luokat | ✅ Palveluluokat noudattavat yksittäisen vastuun periaatetta, joiden nimet osoittavat selkeästi käyttötarkoituksen (AccountService, OrderProcessor, InventoryManager). Jokainen palveluluokka keskittyy yhteen toimialueeseen tai liiketoimintaominaisuuteen. Palveluluokkien metodeilla on yksittäiset, keskitetyt vastuut 20 rivin alle. |
| Käynnistimet | ✅ Käynnistimet delegoivat käsittelijäluokkiin liiketoimintalogiikan sisältämisen sijaan suoraan. Käynnistimen käsittelijän kuvio, jota käytetään yhdenmukaisesti metodin selkeiden nimien kanssa asiayhteyden perusteella (handleBeforeInsert, handleAfterUpdate). Käsittelijäluokat organisoivat logiikkaa käynnistintapahtuman perusteella, jossa on yksittäisiä vastuuhenkilöitä per metodi. |
| Lightning-verkkokomponentit | ✅ Komponentit noudattavat yhden vastuun periaatetta ja selkeitä käyttöliittymiä kokoonpanoon. Jokainen LWC keskittyy yhteen käyttöliittymään (datan näyttö, käyttäjän syöttämät tiedot, navigointi). Komponentit, jotka on suunniteltu koostumukselle, eivät monoliittisille toteutuksille. |
| Palveluokerros | ✅ Palveluluokat sisältävät liiketoimintalogiikkaa riippumatta syöttöpisteestä (käynnistin, API, kulku, erä). Sama palveluluokka käsittelee useita kutsujen konteksteja ilman identtisiä tietueita. Palvelualue erottaa liiketoimintasäännöt esitelmistä ja datan käyttöoikeuksista. |
| Uusi-käytettävät komponentit | ✅ Komponentit, jotka on suunniteltu käytettäväksi useissa projekteissa ja tiimeissä. Määritykseen perustuva toimintatapa, joka käyttää mukautettuja metadatatyyppejä, sallii toimintatavan muutosten ilman koodin käyttöönottoa. Kutsuttavat toiminnot paljastavat Apex deklaratiivisina rakennuspalikoina, joita voidaan käyttää kulusta ja ulkoisesta orkestroinnista. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| God-luokka | ⚡️ Vältä liiallisen vastuun kertymistä yhteen luokkaan. Jaa suuret luokat (yli 500 riviä) keskitetyiksi luokiksi, joilla on yksittäiset vastuut. Järjestele luokat uudelleen, kun ne käsittelevät useita asiaan liittyviä huolenaiheita (OrderProcessorin ei tulisi käsitellä myös sähköpostien lähetystä ja raportointia). |
| Yhdistetyt huolenaiheet | ⚡️ Vältä sekoittamasta käynnistimen logiikkaa, liiketoimintasääntöjä ja tietojen käyttöoikeuksia yhteen luokkaan. Erota esitelmälogiikka ohjaimien liiketoimintalogiikasta. Pidä integraatiossa huomioitavat asiat erillään ydintoimialueen logiikasta. |
| Käynnistimien käynnistimien logiikka | ⚡️ Vältä upottamasta liiketoimintalogiikkaa suoraan käynnistimen tiedostoihin. Älä koskaan käytä yli 300 rivikäynnistintä sisäkkäisillä ehdoilla. Delegoi aina käsittelijäluokille selkeä menetelmän organisointi käynnistimen kontekstin perusteella. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Liiketoimintalogiikka | ✅ Liiketoimintasäännöt, jotka on keskitetty palveluluokkiin, eivät hajautettu käynnistimiin, ohjaimiin tai eriluokkiin. Toimialuekunnat sisältävät tietuetason toimintatavat (vahvistus, oletusarvot, johdetut arvot) yhdenmukaisesti riippumatta siitä, miten tietueet saapuvat järjestelmään. Logiikkaa käytetään uudelleen palvelukerroksen kautta sen sijaan, että sitä kopioidaan eri syöttöpisteissä. |
| Datan käyttöoikeus | ✅ Tietojen käyttöoikeus, joka on abstrakti säiliön tai valitsimen kuvion luokkien jälkeen. SOQL-kyselyt on keskitetty valitsinluokkiin (AccountSelector, OpportunitySelector), jotta kenttien luettelot ja WHERE-lausekkeet ovat yhdenmukaisia. Säiliökuvio sallii testata esimerkkidatalähteitä muuttamatta liiketoimintalogiikkaa. |
| Liittymäsopimukset | ✅ Komponentit kommunikoivat käyttöliittymän kautta toteutuksen lisätietojen sijaan. Apex määrittävät sopimukset kerroksien välillä. Mukautettu metadatan kokoonpano määrittää toimintorajoitukset. Sovellusalustan tapahtumat -ominaisuus tarjoaa viestintäsopimuksia tuottajien ja kuluttajien välillä. |
| Moduulin rajat | ✅ Rajatut kontekstit määrittävät selkeät omistajuusrajat datamalleille ja liiketoimintasäännöille. Jokainen moduuli omistaa sen datan, automatisoinnin ja liiketoimintalogiikan. Moduulit vuorovaikuttavat määritettyjen API-rajapintojen kautta, eivätkä ne jaa tietokantaobjekteja suoraan. Dokumentaatio osoittaa selkeästi, mikä tiimi omistaa mitkä objektit ja palvelut. |
| Riippuvuuskulku | ✅ Riippuvuudet kulkevat yhteen suuntaan (esittely → liiketoiminta → data). Ydinliiketoimintalogiikka ei riipu mistään ulkoisesta, mikä mahdollistaa itsenäisen evoluution. Infrastruktuuriin liittyvät huolenaiheet (kirjoitus, välimuistiin tallentaminen, ulkoiset API-rajapinnat) riippuvat liiketoimintalogiikasta rajapintojen kautta eikä päinvastoin. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Logiikan kopiointi | ⚡️ Vältä käyttämästä identtistä liiketoimintalogiikkaa käynnistimien, API-päätepisteiden ja eräluokkien välillä. Keskitä palvelualueeseen ja käytä uudelleen eri syöttöpisteissä. Kun sama liiketoimintasääntö näytetään useissa luokissa, nouda se jaettuun palveluun. |
| Datan käyttöoikeus hajallaan | ⚡️ Vältä SOQL-kyselyitä, jotka ovat hajallaan käynnistimessä, ohjaimessa ja eräluokissa, joissa on epäjohdonmukaisia kenttien luetteloita ja WHERE-lausekkeita. Keskitä valintaluokkien kyselyitä varmistaaksesi yhdenmukaiset kuviot ja ottaaksesi LDV-optimoinnin käyttöön yhdestä sijainnista. |
| Liiketoimintalogiikka käynnistimissä | ⚡️ Vältä vahvistussääntöjä, kenttien laskutoimia ja työnkulkujen orkestrointia, jotka on upotettu suoraan käynnistimen koodiin. Siirry palveluluokkiin tai toimialuekloihin. Pidä käynnistimet ohuina ja keskity vain oikeille käsittelijöille. |
| Liiketoimintalogiikka ohjaimissa | ⚡️ Vältä monimutkaisia laskutoimia, vahvistuksia tai datan manipulointia Aura/LWC-ohjaimet-metodeissa. Ohjaajien tulisi orkestroida puhelut palvelualueeseen, ei toteuttaa liiketoimintasääntöjä suoraan. |
| Ympyräiset sidonnaisuudet | Vältä paketteja tai luokkia, joilla on ympyräisiä riippuvuuksia, joissa A on riippuvainen B:stä ja B on riippuvainen A:sta. Ratkaise ongelma noutamalla jaetut huolenaiheet erillisiksi moduuleiksi, kääntämällä riippuvuuksien suunta tai käyttämällä tapahtumiin perustuvaa viestintää katkaistaksesi kopioinnin. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Sovellusalustan välimuisti (organisaation osio) | ✅ Organisaation osiossa välimuistiin tallennetut usein käytettävät viitetiedot, mukaan lukien mukautetut metadatan haut, valintaluetteloarvot, kokoonpanoasetukset ja kalliiden toimintojen lasketut tulokset. Oletusarvoinen TTL määritetty datan volatiliteetin perusteella (kuukausittain muuttuvien viitetietojen tunnit, usein päivitettyjen määritysten minuutit). Välimuistiin tallennusstrategia estää ristiriidat eri datatyypeillä. |
| Sovellusalustan välimuisti (istunnon osio) | ✅ Käyttäjäkohtaiset valinnat, lasketut personalisointitiedot ja istunnon vaikutusalueen tila, jotka on tallennettu istunnon välimuistiin. Istunnon välimuistia ei käytetä tiedoille, jotka tulisi jakaa käyttäjille. Välimuistin mitätöintistrategia käsittelee käyttäjien valintojen päivitykset oikein. |
| Lightning Data -palvelu | ✅ LDS tarjoaa asiakassivun tietueiden automaattisen välimuistiin tallentamisen Lightning. CRUD-vakiotoiminnot käyttävät LDS:ää mukautettujen Apex sijaan. LDS vähentää tarpeettomia palvelimen matkoja ja tarjoaa optimaalisia käyttöliittymäpäivityksiä. Komponentit hyödyntävät jaettua LDS-välimuistia sivulla. |
| Mukautetut metadatatyypit | ✅ Mukautetuissa metadatatyypeissä säilytetyt kokoonpano- ja toimintatavat, eivätkä kovakoodatuissa luokissa. Mukautettua metadataa voidaan ottaa käyttöön eri ympäristöissä muutosjoukkojen tai lähdekohtaisen kehityksen kautta. Mukautetun metadatan muutokset eivät vaadi täyttä käyttöönottosykliä. Tallenna mukautettuja metadatan kyselyitä välimuistiin sovellusalustan välimuistissa suorituskyvyn parantamiseksi. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Kysely silmukassa | ⚡️ Vältä suorittamasta SOQL:ää iterointisulkeissa. Kysele kaikkia tarvittavia tietueita yhdellä SOQL-lausekkeella silmukoiden ulkopuolella. Järjestele tulokset Mapsiin ylätason tunnuksen perusteella hakuun iteroinnin aikana. Tämä on yksi yleisimmistä Salesforcen antikuvioista. |
| Toistuvat kyselyt | ⚡️ Vältä kyselemästä samaa mukautettua metadataa, mukautettuja asetuksia tai viittaamasta dataan useita kertoja per transaktio. Kysele kerran, tallenna sovellusalustan välimuistiin tai transaktioiden staattiseen muuttujaan ja käytä transaktiota uudelleen. |
| Älä käytä välimuistin strategiaa | ⚡️ Vältä kyselemästä usein käytettyjä viitetietoja toistuvasti ilman välimuistiin tallentamista. Toteuta sovellusalustan välimuisti mukautetulle metadatalle, kokoonpanolle ja lasketuille tuloksille. Määritä sopiva TTL datan volatiliteetin perusteella. |
| Välimuisti ilman virheenkorjausta | ⚡️ Vältä datan tallentamista välimuistiin ottamatta huomioon mitätöintistrategiaa. Määritä välimuistin TTL, joka soveltuu päivitystiheykseen. Ota välimuistin tyhjennys käyttöön manuaalisesti, kun lähdedata muuttuu, jos yksittäinen TTL ei riitä. |
| Ei-hallitun istunnon tila | ⚡️ Vältä olettamasta, että istuntotila säilyy sivujen navigoinnissa ilman vahvistusta. Lightning tulisi käsitellä tilan päivitys sivujen lataamisen yhteydessä. Käytä Lightning Data Servicea tilojen automaattiseen synkronointiin. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Ratkaisun arkkitehtuurin suunnittelu | ✅ Arkkitehtuurin suunnittelu tapahtuu ennen merkittävää rakennusinvestointia, mukaan lukien vaatimusten analyysi (toiminnallinen ja ei-toiminnallinen), hallintarajoitusten analyysi odotetuille datamäärille, vaatimuksiin sopivan kuvion valinta ja komponenttien suunnittelu, joka määrittää tärkeimmät komponentit ja rajapinnat. |
| Suunnittelukuvion valinta | ✅ Käytettyä Salesforce-suunnittelukuviota käytetään yhdenmukaisesti: Palvelutasokuvio liiketoimintalogiikan uudelleenkäytölle, Säiliö-/valintakuvio datan käyttöoikeuksien abstraktiolle, Vaihdettavat algoritmit, Tietuetason toimintatapa, Käynnistimen käsittelijän kuvio yhdenmukaiselle käynnistimen organisaatiolle. |
| Arkkitehtuurin päätöstyötietueet | ✅ Merkittävät arkkitehtuuripäätökset, jotka on dokumentoitu versioiden hallintaan tallennetuissa ADR-osoitteissa. ADR:t sieppaavat asiayhteyden (liiketoiminnan edistäjät, tekniset rajoitukset), päätöksen (mitä valittiin), harkitut vaihtoehdot (miksi toiset hylättiin) ja seuraukset (liiketoimet, tekninen velka, uudelleenkäynnistimet). |
| Laadi vs. Osta arviointi | ✅ AppExchange edeltää mukautettuja kehityspäätöksiä käyttämällä omistajuuden kokonaiskustannus-analyysiä. Arviointiperusteisiin sisältyvät strateginen arvo (kilpailukykyinen erottaja vs. tuote), TCO-vertailu (rakennustyöt, huolto, päivityskustannukset), integraation monimutkaisuus ja poistumiskustannukset, jos ratkaisu osoittautuu riittämättömäksi. |
| Governor Limit -analyysi | ✅ Arkkitehtuurin suunnittelu osoittaa, mikä hallintaohjelma rajoittaa suunnittelua eniten odotettujen datamäärien ja transaktioiden kuvioiden perusteella. Transaktiot, jotka on suunniteltu kuluttamaan alle 80 % yksittäisestä hallintarajoituksesta ruuhka-olosuhteissa. Marginaali, joka on laadittu kasvulle, tuleville ominaisuuksille ja odottamattomille käyttökuvioille. |
| Riskien arviointi | ✅ Tekniset riskit, jotka on tunnistettu sovellusalustan rajoja laajentaville arkkitehtonisille lähestymistavoille. Jokaiselle merkittävälle riskille määritetyt lieventämistrategiat. Prototyyppityö tai käsitteen todistustyö vahvistaa korkean riskin teknisten lähestymistapojen oletukset ennen täyden rakentamisen sitoumusta. |
Anti-Mallit
| Mistä etsiä | Miltä huono näyttää |
|---|---|
| Ei suunnitelmaa | ⚡️ Vältä rakentamisen aloittamista analysoimatta datamääriä, hallintarajoituksia tai kuvion valintaa. Arkkitehtuurin suunnittelutyöpajan tulisi tunnistaa tärkeimmät rajoitukset, valita kuviot ja vahvistaa hallintarajoitukset ennen rakentamisen aloittamista. |
| Dokumentaattiset päätökset | ⚡️ Vältä tekemästä kokouksissa rakenteellisia päätöksiä, jotka eivät huomioi asiayhteyttä, perustelua, vaihtoehtoja tai seurauksia. Käytä versiohallinnassa säilytettyjä arkkitehtuurin päätöstyötietueita säilyttääksesi päätösten asiayhteyden tuleville tiimin jäsenille. |
| Ei rakenna vs. osta analyysi | ⚡️ Vältä luomasta mukautettuja ratkaisuja ilman AppExchange. Arvioi 3-5 tärkeintä relevanttia pakettia ennen mukautetun kehityksen tekemistä. Vertaa TCO-arvoja, mukaan lukien toteutustehtävät, huolto, päivityskustannukset ja poistumiskustannukset. |
| Alitason suunnittelu | ⚡️ Vältä suunnittelulta vain tämänhetkisille datamäärille ilman kasvun ennustamista. Datan kasvun ennustaminen 2-3 vuoden ajalta. Suunnittele kyselykuvioita, joiden valikoivuutta vahvistetaan nykyisten määrien perusteella 5–10 kertaa. Rakenna kasvun arkkitehtuurin marginaali. |
Kuvio
| Mistä etsiä | Miltä hyvä näyttää |
|---|---|
| Toisen sukupolven hallitut paketit (2GP) | ✅ 2GP käytetään uusille hallituille paketeille, jotka vaativat nimitilan eristämistä, AppExchange ja IP-suojausta. Lähdepohjainen kehitysprosessi ja sovellusten modulaarinen kehitys. Pakettien sidonnaisuuksia hallitaan erikseen. Semanttisella versioinnilla julkaistut versiot. |
| Lukitsemattomat paketit | ✅ Lukitsemattomat paketit, joita käytetään sisäisille yrityssovelluksille, jotka vaativat modulariteettia ilman nimitilan rajoituksia. Pakettien itsenäinen käyttöönotto ilman organisaatiosta riippuvia artefakteja. Pakettien sidonnaisuuksia seurataan oikean käyttöönoton järjestämiseksi. Sisäisille paketeille määritetty versiointistrategia. |
| Moduulin rajat | ✅ Tyhjennä jokaiselle paketille määritetyt omistajuusrajat. Jokainen paketti omistaa datamallinsa, liiketoimintasääntöjään ja automatisointinsa. Paketit vuorovaikuttavat määritettyjen käyttöliittymien kautta objektien suoran käyttöoikeuden sijaan. Dokumentaatio tunnistaa pakettien omistajuuden ja pakettien väliset sopimukset. |