Lue päivitysaikatauluistamme tästä.

Yhdistelmäratkaisut säätyvät nopeasti ja vakaammin. Yhdistettäväksi rakennettu järjestelmä on rakennettu hyödyllisiksi yksiköiksi, eli rakennuspalikoiksi, jotka toimivat hyvin toistensa kanssa ja jotka voidaan vaihtaa helposti käyttöön ja pois käytöstä. Yhdistettävyyden rakentaminen järjestelmään sallii sinun tuoda käyttöön uusia ominaisuuksia tai poistaa teknisiä velkoja uudelleenrakentamalla tai kokoamalla uudelleen yksittäisiä järjestelmän yksiköitä. Yhdistettävyys mahdollistaa nopeampia ja ennustettavampia toimitussykliä ja julkaisuja, koska tiimit voivat keskittyä luomaan ja tarjoamaan hyödyllisiä ominaisuuksia pienempien muutosten avulla.

Yhdistelmäjärjestelmät sallivat yritysten sopeutua nopeammin ja vakaammin — riippumatta siitä, onko kannustin yrityksen sisäinen vai ulkoisten tekijöiden aiheuttama. Yhdistettävyys auttaa järjestelmiä olemaan vakaampia ja voi auttaa tekemään ratkaisuista ja arkkitehtuurikuvioista enemmän tarkoittavia.

Voit tehdä Salesforce-ratkaisuistasi luettavampia rakentamalla kolme tärkeintä tapaa: huolenaiheiden erottaminen, yhteentoimivuus ja pakkaaminen. Alla näet näiden tapojen suhteen kahdella tavalla: yhdelle yksikölle yhdistetyssä järjestelmässä ja useille yksiköille yhdistetyssä järjestelmässä.

Yksittäinen, yhdistettävä yksikkö:

Kokoonpanojärjestelmä:

Ohjelmistojen ja järjestelmäarkkitehtuurin peruskäsitteenä huolenaiheiden erottaminen edellyttää useiden huolenaiheiden tunnistamista laajemmassa järjestelmässä, joka voidaan erottaa modulaarisiin yksiköihin. Huolenaiheiden vahva eriytyminen järjestelmässä vaatii hyödyllisten yksiköiden luomista sovelluslogiikalle ja toiminnoille järjestelmässä. Pienemmät yksiköt auttavat sovellusten toimitus- ja huoltotiimejä ymmärtämään helpommin, miten ja missä tehdä muutoksia, ja vähentämään suurten järjestelmien häiriöitä. Pienemmät yksiköt auttavat sinua myös selvittämään, miten ja mihin keskittyä, kun käsittelet teknisiä velkoja, ja auttavat parantamaan järjestelmäsi yleistä lukemista.

Voit parantaa huolenaiheiden erottamista Salesforce-organisaatiossasi keskittymällä liiketoimintamahdollisuuksiin ja tilan hallintaan.

Salesforce-järjestelmissä tärkein lähestymistapa huolenaiheiden erottamiseen on käyttää liiketoimintaan keskittynyttä perspektiiviä tunnistaakseen ja organisoidakseen järjestelmässä olevia modulaarisia yksiköitä (tai ominaisuuksia). Tämä ei ole sama asia kuin suunnitteluun keskittyvä näkymä, joka tunnistaa yksiköt niiden teknisen toiminnon perusteella. Liiketoimintaan perustuva näkökulma huolenaiheiden erottamiseksi edellyttää, että järjestelmäsi koodi ja mukautukset organisoidaan niiden tarjoaman palvelun perusteella yritys- ja yrityskäyttäjille. Tämän lähestymistavan käyttäminen ei tarkoita, että ohittaisit tarpeettomien tai identtisten teknisten toimintojen mahdollisuuksia järjestelmässä. Se tarkoittaa pikemminkin, että tekniset palvelut on kartoitettu selkeästi organisaatioperiaatteeseen, joka on lopulta läpinäkyvä yritykselle.

Liiketoimintaominaisuuksiin keskittyminen auttaa varmistamaan, että liiketoiminta-analyysien ja tutkimustiimien väliset välitykset toimitustiimeille ovat mahdollisimman suoria. Jos sovellusrakentajilla ei ole aavistustakaan siitä, mihin heidän työyksikkönsä on kartoitettu yhdistettävään arkkitehtuuriin, sinulla on sotku, et yhdistettävää sovellusympäristöä. Epäselvät kartoitukset yrityksen vaatiman lopputason ja organisaation modulaaristen yksiköiden välillä parantavat myös kehitystiimien tai toimittajien mahdollisuuksia luoda tarpeettomia toimintoja järjestelmään.

Ota seuraavat asiat huomioon ohjataksesi toiminnalliset yksiköt liiketoimintamahdollisuuksiin:

• Aloita tekemällä töitä. Keskity käyttäjien ja yrityksen tekemisiin tehtäviin (JTBD). Tony Ulwickin kehittämä JTBD-lähestymistapa keskittyy ”työn” tai todellisen tarkoituksen ymmärtämiseen, jota ihmiset yrittävät saavuttaa käyttämällä tuotetta tai palvelua. Se on enemmän abstraktiota kuin käyttäjien rooleihin liittyvät tehtävät tai liiketoimintaprosessin yksittäiset vaiheet. Esimerkiksi tehtävät, kuten identtiset tarkastukset ja osoitteiden vahvistukset, saattavat kuulua korkeampaan järjestykseen ”luoda yhden näkymän asiakkaasta”. Kun olet ymmärtänyt nämä ylemmän tason liiketoimintaominaisuudet, voit aloittaa järjestelmäsi osien kartoittamisen niihin.
• Käytä kykyjä, älä raportointirakenteita. Liiketoimintayksiköidesi sisäinen hierarkia ei ole välityspalvelu hyödyllisille kyvyille tai tehtäville. Yrityksesi sisäisellä hierarkialla on merkittävä vaikutus prosesseihin ja tiimirakenteisiin (puhumattakaan budjetteista). Nämä ovat tärkeitä logistisia huomioitavia asioita. Yrityksen toiminnalliset tarpeet toimivat kuitenkin abstraktisemmin kuin logistiikka. Jos olet luomassa moduulia, joka tarjoaa raportointirakenteen korkeamman järjestyksen toiminnon sijaan, sinun täytyy ehkä suorittaa lisätoimenpiteitä tunnistaaksesi, miten moduuli liittyy liiketoimintaominaisuuksiin.
• Ole iteratiivinen. Aloita tekemällä yhteistyötä yrityksen kanssa tunnistaaksesi, mikä kapasiteetti voisi toimia vähimmäissuorituskykytuotteelle (MVP). Kun olet tunnistanut kyvyn, aloita sen laatiminen. Kun rakennat, tunnista prosessit, metadata ja tapahtumat tai viestit, jotka ovat keskeisiä luomassasi toiminnallisessa yksikössä. Tunnista kaikki prosessit, metadata ja tapahtumat tai viestit, jotka ovat ulkoisia sidonnaisuuksia. Kun toiminnallisia yksiköitä suunnitellaan, ota käyttöön API-hallinta ja riippuvuuksien hallinta rakentaaksesi yksiköitä, jotka toimivat hyvin toistensa kanssa (erillisten yksiköiden sijaan).

Alla oleva kuvioiden ja antikuvioiden luettelo näyttää, miltä oikea (ja huono) liiketoimintatoimintojen suunta näyttää Salesforce-ratkaisussa. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen rakentamista tai tunnistaaksesi järjestelmäsi alueet, jotka täytyy uudelleenrakentaa.

Lisätietoja Salesforcessa saatavilla olevista työkaluista, jotka auttavat sinua keskittymään paremmin liiketoimintamahdollisuuksiisi, on kohdassa Composable-työkaluihin liittyvät työkalut.

Osavaltion hallinta keskittyy tietojen siirtämiseen järjestelmässä eri aikoina. Tehokas tilan hallinta sallii sovellusten käsitellä monimutkaisia datakulkuja tai vuorovaikutuksia vähintään suunnittelemattomilla tai määrittämättömillä lopputuloksilla. Osavaltioiden hallinta modulaarisessa Salesforce-organisaatiossa tarkoittaa selkeiden polkujen luomista yksiköiden sisäisille ja välisille logiikakulkuille sekä hienovaraisia polkuja suunnittelemattomille suorituskykytoimille. Osavaltioiden hallinta mahdollistaa yhdenmukaisten logiikkavirtojen muodostamisen Salesforce-sovelluksen modulaarisia yksiköitä. Useimmissa tapauksissa tämä vaatii yhteensopivuutta yksiköiden välisen tietovirran rakentamiseksi.

Heikosti yhdistettyjen yksiköiden tilan hallinnassa esiintyvät vaikeudet johtavat usein monoliittiseen sovelluskehitykseen Salesforcessa. Näet tämän suurissa ”monokulkuissa”, jotka on rakennettu pyrkimyksenä orkestroida monimutkainen prosessi yksittäisessä kulussa. Toinen esimerkki on massiiviset Apex-luokat, jotka orkestroivat monimutkaisia prosesseja spaghettikoodin avulla, tai pitkä sarja kertakäyttöisiä menetelmiä. Tämäntyyppiset sovellusarkkitehtuurit vaikeuttavat refaktorointia ja virheenkorjausta ja pidentävät tiimin uusien jäsenten tai toimittajien perehdytysaikoja. Ne vähentävät myös yritykselle toimitettujen sovellusten arvoa, koska toimintoja ei voi käyttää uudelleen.

Ota huomioon seuraavat seikat hallitaksesi osavaltioita modulaarisessa Salesforce-organisaatiossa:

• Päätä, milloin haluat käyttää osavaltiokohtaisia versus tilattomia kuvioita. Osavaltio-kuviot säilyttävät tietoja suorituspolussa, mutta ei osavaltio-kuviot. Vapaasti yhdistetyssä järjestelmässä tilattomat kuviot sallivat komponenttien uudelleenaktivoinnin nopeammin ja vähemmän sivuvaikutuksia. Tilattomat kuviot eivät kuitenkaan sovellu kaikille käyttötarkoituksille. Jos rakennat komponentteja datatoiminnoille, tilaiset kuviot voivat auttaa datan eheydessä ja yhdenmukaisuudessa kaikissa järjestelmissäsi. Käytä tilaa sisältävää kuviota, jos komponenttisi täyttää jonkin seuraavista ehdoista:
  • Tietoisuus sijainnista suuremmassa suorituspolussa on välttämätöntä komponentin toimintatavoille
  • Komponentin toimintatapa täytyy muuttaa alempien toimintojen tulosten perusteella (esimerkiksi sen täytyy muuttaa suoritusta alempien komponenttien periytymisviestien/virheiden/onnistumisviestien perusteella).
  • Komponentin täytyy odottaa vastauksia ulkoisesta järjestelmästä tai alemmasta järjestelmästä töidensä suorittamiseksi loppuun.
• Luo hyödyllisiä kategorioita tilatiedoille. Tila on moniselitteinen termi, jota voidaan soveltaa Salesforce-organisaation sisällä (ja sen ulkopuolella) olevan niin laajaan ja laaja-alaiseen tietoon, että termi itsessään on lähes merkityksetön. Tästä syystä ensimmäinen välttämätön vaihe osavaltiokuvioiden rakentamisessa on luoda järjestelmässäsi tärkeimmille osavaltiopolkuille (tai tilojen toimintatapoille) tarkoittavia kategorioita. Joitakin huomioitavia luokkia:
  • Navigointi ja lomakkeet
  • Tietokantaoperaatiot
  • Erä- ja joukkotoiminnot
  • Virheet
• Määritä dataan liittyvät tilat tietokannan transaktioiden perusteella. Sovellusalustan sisäänrakennetut toimintatavat rajoittavat useimmat Salesforce-datan tiloissa huomioitavat asiat. Älä yritä hallita tai ohittaa tätä toimintatapaa. Suunnittele se ja sen kanssa. Suunnittele ratkaisuja, jotka minimoivat tai poistavat jaetun transaktiologiikan. (Lisätietoja on kohdassa tietojen käsittely).
• Tunnista tilat, jotka tapahtuvat toiminnallisten yksiköiden sisällä (ja kaikissa). Kun kokoat toiminnallisia yksiköitä suuremmiksi järjestelmiksi, ota huomioon, kun yhdistät tilatonta ja tilatonta komponenttien toimintatapaa, ja vältä yhdistelmät, jotka voivat luoda loputtomia silmukoita tai aukkoja käsittelyssä.
• Määritä käsittelytoimet. Mieti, mitä viestintä- tai tapahtumien kuvioita komponentit käyttävät lähettääkseen osavaltioihin liittyviä tietoja järjestelmän toiselle osalle. Varmista, että olet rakentamassa transaktioiden tietoisuutta ja käsittelemässä komponenttejasi. Älä sisällytä transaktioiden jaettuja logiikoita myönnöksiisi.
• Luo kartoituksia prosessien kaavioiden ja tilojen välille. Prosessien kaaviot kuvaavat vaiheet, jotka siirtävät tietoja järjestelmässäsi eri aikoina. Osavaltio-kaavio näyttää todelliset muutokset tiedoissa (tila). Käytä Salesforce-kaavioiden muotojen metadatan alapalkkiota sieppaamaan prosessisi jokaisessa vaiheessa muuttuvia tietoja. Jos erotat prosessi- ja tilakaaviot toisistaan, muista linkittää ne toisiinsa. Tätä käsitystä ei pidä sekoittaa prosessien tai järjestelmäasettelujen tämänhetkisen ja tulevan tilan kaappaamiseen suunnittelun ja toteutuksen aikana, koska se ei koske järjestelmän läpi liikkuvia tietoja.

Alla oleva kuvioiden ja antikuvioiden luettelo näyttää, miltä oikea (ja huono) osavaltion hallinta näyttää Salesforce-ratkaisussa. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Lisätietoja Salesforce-työkaluista osavaltion hallintaan on kohdassa Yhdistettävissä olevat työkalut.

Seuraava taulukko näyttää valikoiman kuvioita, joita haluat etsiä (tai rakentaa) organisaatiossasi, sekä vasta-kuvioita, joita haluat välttyä tai joilla haluat korjata.

✨ Tutustu muihin huolenaiheiden erottamista koskeviin kuvioihin kohdasta Kuvioiden ja anti-kuvioiden tutkintaohjelma.

Yhteensopivuutta varten rakennetuissa järjestelmissä komponentit voivat vaihtaa tietoja ja toimia tehokkaasti yhdessä. Yhteensopivuus on tärkeää, jotta modulaarinen järjestelmä voidaan yhdistää erillisen järjestelmän sijaan. Yhteensopivuutta voi olla vaikea saavuttaa vapaasti yhdistetyssä järjestelmässä. Sinun täytyy laatia standardeja yhdenmukaisille integraatiomenetelmille, jotka eivät heikennä yksiköiden välistä riippumattomuutta tai järjestelmän kokonaisvaltaista huolenaiheiden erottamista.

Yhteensopivuus vaikuttaa myös käyttäjäkokemusten laatuun. Käyttäjäsi odottavat, että yhdelle alueelle luotu data (kuten tilaustiedot) on käytettävissä toisessa (kuten markkinointikampanjat), ja rakentajasi odottavat, että jos he oppivat tekemään jotain (kuten luomaan kulun tai todentamaan API:n), he näkevät tutut tekniikat toimivan, kun he siirtyvät seuraavaan ongelmaan. Yhteensopivuutta varten suunnittelun epäonnistuminen aiheuttaa tarpeettomia arkkitehtuuria, replikoitua dataa, prosessien tehottomuutta sekä kasvavia kehitys- ja tukikustannuksia.

Voit luoda yhteentoimivuutta modulaarisiin järjestelmiin viestinnän ja tapahtumien avulla sekä API-hallinnan avulla.

Viestit ja tapahtumat ovat kaksi tapaa, joilla voit ottaa komponentteja käyttöön järjestelmässä lähettääksesi ja vastaanottaaksesi tietoja. Tapahtumat ja viestit ovat samankaltaisia niiden sisällön perusteella. Tärkein eroavaisuus on lähettäjän toimintatapa. Viestin lähettävä komponentti lähettää dataa tavallisesti tiettyyn kohteeseen ja odottaa vastaanottajalta jonkinlaista vastausta. Komponentti sen sijaan lähettää tapahtuman, kun jotain on tapahtunut. Tiettyä kohdetta tai vastauksen odotettavuutta ei ole. Nämä toimintatavan eroavaisuudet tukevat eri viestintäkuvioita. Viestit tukevat tilallisia viestintäkuvioita ja tapahtumat tukevat tilattomia viestintäkuvioita. (Lisätietoja tästä erotuksesta on kohdassa Valtion hallinta).

On tärkeää, että tiimit noudattavat protokollia ja käyttävät tapauksia viestinnässä ja tapahtumissa. Epäselvät standardit voivat johtaa eri kuvioiden yhdistelmään järjestelmässä, mikä johtaa seuraaviin:

• Suorituskyky- ja skaalattavuusongelmia, joissa väärät kuvioita sovelletaan tiettyyn käyttötarkoitukseen
• Epäjohdonmukainen käsittely, joka tekee järjestelmästä epävakaan loppukäyttäjille
• Pidemmät vianmääritysajat ja monimutkaisempia huoltoprosesseja

Ota huomioon seuraavat seikat, kun suunnittelet viestejä ja tapahtumia luodaksesi Salesforce-organisaatiossasi liukuvia rakenteita:

• Tunnista synkronoinnin ja asynkronoinnin käyttötarkoitukset. Tapahtumat sallivat löysästi yhdistetyn, tilattoman ja ei-synkronoidun viestinnän järjestelmässä. Messaging sallii tarkemman hallinnan, tilan ja synkronoinnin viestintäkuvioissa. Kun päätät, milloin viestejä tai tapahtumia käytetään, sinun täytyy päättää, tarvitseeko viestisi olla synkronoitu (ja mahdollisesti estävä) vai ei-synkronoitu ja ei-estävä.
• Määritä datarakenteet huolellisesti. Komponenttien välittämien tietojen rakenne on tärkeä osa vapaasti yhdistetyn järjestelmän hallittavuuden ja yhdenmukaisuuden pitämistä. (Lisätietoja tästä on kohdassa API-hallinta). Viestin tai tapahtuman suunnittelussa huomioitava tekijä on, kuinka usein tietojen rakenne täytyy muuttaa. Kun viesti tai tapahtumarakenne on määritetty ja otettu käyttöön järjestelmässäsi, päivitysten käsittely voi olla vaikeaa — varsinkin jos tapahtumaa tai viestiä käytetään jo tietojen lähettämiseen ulkoiseen järjestelmään.
• Oikean kokoiset viestit. Yleisesti ottaen suosittelemme pitämään viestien koot pieninä. Viestin koko ja viestien määrä ovat kuitenkin tasapainossa. Järjestelmät voivat käsitellä pienempiä määriä dataa nopeammin. Käsittelyn toimenpiteeseen liittyy lisäkustannuksia, koska vastaanottajien täytyy purkaa pakkaus, tulkita ja määrittää, mitä tehdä vastaanottamilleen tiedoille. Näiden vaiheiden suorittaminen saattaa kestää vähäistä aikaa, mutta ne voivat muodostaa ja rasittaa järjestelmiä laajalti. Vältä suunnittelua, joka vaatii, että järjestelmän komponentit käsittelevät monta pientä viestiä peräkkäin töiden suorittamiseksi. Jos haluat tehdä viesteistäsi oikean kokoisia, mieti suunnitellaksesi vähimmäismäärän tietoja, joita downstream-komponenttien täytyy käsitellä ja toimia lähetettyjen tietojen perusteella onnistuneesti ilman, että jokainen downstream-komponentti voisi pyytää tai käsitellä useita seurantaviestejä.
• Suunnittelu skaalattavuutta varten. Leveästi yhdistetyt komponentit voivat helpottaa arkkitehtuurisi skaalaamista. Komponenttien välisten sidonnaisuuksien poistaminen sallii tiimien parantaa minkä tahansa yksittäisen komponentin suorituskykyä tai skaalattavuutta vähentämällä vaikutuksia muihin. Kuitenkin irti kytketyt komponentit lisäävät arkkitehtuuriisi myös paljon monimutkaisuutta (varsinkin kun kyse on tilan hallinnasta). Tunnista prosessit, joiden täytyy olla tiiviimmin sidoksissa logiikkaan tai riippuvuuksiin käyttäjäkokemuksen tai datan eheyden vuoksi — äläkä yritä tuoda asynkronointiin tai tapahtumiin perustuvia kuvioita kyseisiin prosesseihin. Käytä sen sijaan synkronointiin/viesteihin perustuvia kuvioita ja virheiden asianmukaista käsittelyä.

Alla oleva kuvioiden ja antikuvioiden luettelo näyttää, miltä oikea (ja huono) viestintä ja tapahtumat näyttävät Salesforce-ratkaisussa. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen niiden rakentamista tai tunnistaaksesi järjestelmässäsi uudelleenrakennettavat kohteet.

Lisätietoja Salesforcen viestintä- ja tapahtumavälineistä on kohdassa Composable-ominaisuuteen liittyvät työkalut. Lisätietoja tapahtumien kuvion tai työkalun valitsemisesta tietylle käyttötarkoitukselle on Arkiteetin opas tapahtumiin perustuvaan arkkitehtuuriin Salesforcessa.

Asianmukaisen sovellusten ohjelmointiliittymän (API) hallinnan luominen Salesforce-ratkaisussa sallii järjestelmäsi yksittäisten komponenttien noudattaa ennustettavia viestintäkuvioita. Salesforce tarjoaa sisäänrakennettuja ja turvallisia API-rajapintoja, joita voi käyttää kommunikointiin Salesforcen ulkopuolisten järjestelmien kanssa. (Lisätietoja Salesforce Platform API -rajapinnoista on kohdassa Arkkitehtuurin perusteet).

Tehokas API-hallinta Salesforce-ratkaisuissa on avainasemassa todellisten yhdistettävien arkkitehtuurien rakentamisessa. Sen avulla Salesforce-organisaation komponentit voivat lähettää ja vastaanottaa tietoja tehokkaasti. Lisäksi se sallii ratkaisujen rakentajien noudattaa selkeitä protokollia siitä, miten heidän laatimansa komponentit kommunikoivat järjestelmän muiden komponenttien kanssa, ja auttaa heitä tunnistamaan huonoja toteutuksia ajoissa. Lisäksi se sallii ratkaisujen rakentajien keskittyä tarkemmin tiettyyn komponenttiin, jota he rakentavat tai refaktoroivat, mikä parantaa tuottavuutta ja laatua.

Enterprise-tason API-hallinta on erillinen aihe — ja se voidaan parhaiten saavuttaa kattavalla API-hallintatyökalulla. (Lisätietoja tästä aiheesta MuleSoftin näkökulmasta on kohdassa Mikä on API-hallinta?).

Ota huomioon seuraavat seikat, kun rakennat API-hallintaominaisuuksia Salesforce-ratkaisuihisi:

• Katso, että API-rajapinnat ovat ennustettavia viestintäkuvioita tai sopimuksia. Input- tai output-muuttujien datatyyppi, muuttujien nimet, tietojen osat, jotka tulisi (tai ei tulisi) näyttää tietyssä kuviossa — nämä ovat avaimia tehokkaaseen API-hallintaan. Näiden määritelmien tulisi näkyä suunnittelun standardeissasi, ja tiimien tulisi voida nähdä, miten nämä määritelmät on otettu käyttöön järjestelmäsi tietyissä osissa dokumentaatiosi kautta. Eräs tapa tarkastella vaikeuksia, jotka liittyvät muutosten yhdistämiseen uudesta kehitysympäristöstä integraatioympäristöön, on tarkastella niitä todisteena siitä, missä API-viestintä on toteutettu heikosti (tai et ehkä ole edes API-määritelmää).

• Älä rajoita API-rajapintojen ajattelua vain koodaukseen. API määrittää tässä asiayhteydessä viestin rakenteiden ja muuttujien yhdenmukaisuuden. Kunhan tämä yhdenmukaisuus säilyy, API voidaan toteuttaa koodissa sekä deklaratiivisissa mukautuksissa, kuten automaattisesti käynnistyvissä (tai sovellusalustan tapahtumien käynnistämissä) kulkuissa tai jopa kulkumalleissa. Perusta päätöksesi sen perusteella, mitä haluat määrittää koodissa tai kuluissa, äläkä API-toteutukselle, vaan paketoitavuuteen ja testaatavuuteen.

• Pidä elinkaaresi ja versioinnin yksinkertainen. Kuten kaikilla sovelluskehityksen osilla, API-rajapinnoilla on elinkaari: määritä, rakenna, testaa, ota käyttöön ja ylläpidä (mukaan lukien poistaminen käytöstä). Salesforce Platform API -rajapinnat julkaistavat useita versioita kalenterivuoden aikana sovellusalustan nopean julkaisusyklin vuoksi. (Lisätietoja tästä toimintatavoista on kohdassa Salesforcen arkkitehtuurin perusteet). Tämä tarkoittaa, että sovellusalustan API:illa on melko monimutkainen elinkaari, koska tietyn API:n useita versioita täytyy ylläpitää ja saatavilla Salesforce-asiakkaille. Tämä monimutkaisuuden taso soveltuu PaaS-käyttötarkoituksiin — mutta se on todennäköisesti tarpeeton monimutkaisuus sovellusalustan ratkaisujen arkkitehtuurillesi (katso: Lukuoikeuden vastaiset kuviot). Keskity määrittämään API:lle selkeä käyttötarkoitus (esimerkiksi virheiden käsittely) ja selkeyttämään perustason määritelmiä. Valitse vain yksi API:n versio.

• Tee API-rajapinnoistasi havaittavissa, käytettävissä ja hallittavissa. Dokumentoi API-rajapintasi, jotta potentiaaliset kuluttajat voivat löytää käytettävissä olevat API-rajapinnat, jotka muodostavat yhteyden niihin helposti. API-rajapintojen täytyy toimia saumattomasti osana mahdollisuuksien maisemaa.

• Ole iteratiivinen. Keskity määrittämään ja toteuttamaan vain yksi sisäinen API kerrallaan. Näin voit keskittyä API-määritelmän nopeaan iterointiin, löytää oikean lomakkeen yhdelle tuetulle versiollesi ja laatia parhaita käytäntöjä toteutuksen kokemuksesta.

Alla oleva kuvioiden ja antikuvioiden luettelo näyttää, miltä oikea (ja huono) API-hallinta näyttää Salesforce-ratkaisussa. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen rakentamista tai tunnistaaksesi järjestelmäsi alueet, jotka täytyy uudelleenrakentaa.

Lisätietoja Salesforcessa käytettävissä olevista työkaluista, jotka auttavat sinua luomaan yhteentoimivuutta, on kohdassa Kokoonpanoon liittyvät työkalut.

Seuraava taulukko näyttää valikoiman kuvioita, joita haluat etsiä (tai rakentaa) organisaatiossasi, sekä vasta-kuvioita, joita haluat välttyä tai joilla haluat korjata.

✨ Tutustu enemmän yhteensopivuutta koskeviin malleihin Pattern & Anti-Pattern Explorerissa.

Pakattavuuden luominen Salesforce-organisaatiossa tarkoittaa, että organisaation toiminnot saadaan yksiköistä, jotka voidaan kehittää ja ottaa käyttöön itsenäisesti ja luotettavasti paketeina. Ihannetapauksessa nämä yksiköt määritetään tyyppinä toisen sukupolven paketti (joko lukitsemattoman paketin tai hallitun paketin ISV:ille). Huomautus: Koska hyvin rakennetut ratkaisut käyttävät vain näitä pakettityyppejä, ensimmäisen sukupolven hallitut paketit eivät kuulu tähän.

Yksi asia on määrittää huolenaiheiden erittely ja luoda toiminnallisia yksiköitä Salesforce-organisaatiossa. Voit myös purkaa sidonnaisuuksia ja hallita niitä selkeästi, jotta voit versioida yksiköt onnistuneesti paketin artefakteina. Tämän vakauden ja metadatan eristämisen saavuttaminen vaatii merkittävän DevOps- ja arkkitehtuurisen kypsyyden tason. Lisäksi se nopeuttaa kehitysaikoja, parantaa sovellusrakentajan käyttökokemusta ja tarjoaa ennustettavuutta ja hallintaa julkaisujen ja julkaisujen hallintaan. Kaikki organisaatiot eivät voi tukea infrastruktuuria, jota tarvitaan tehokkaiden pakettien määrittämiseen, ylläpitoon ja kehittämiseen. Paketoinnin saavuttamisen tulisi kuitenkin olla lähes kaikkien Salesforce-organisaatioiden päätavoite.

Voit parantaa paketoitavuutta Salesforce-ratkaisuissasi keskittymällä löysään yhdistämiseen ja riippuvuuksien hallintaan.

Järjestelmässä, jossa on löysä kytkentä, yksittäisiä osia ei ole sidottu vahvasti toisiinsa. Monet yhdistettävän järjestelmän eduista johtuvat irrottamisesta. Paketoitavissa järjestelmissä pakettien (ja organisaatioiden) välisen irrotettavan yhteyden saavuttaminen sallii sinun käyttää hyvin määritettyjä paketteja ja tehokkaampia kehityssykliä paketteja käyttäville tiimeille.

Salesforce Platformissa voit laatia paketteja, jotka ovat tiiviisti sidoksissa tiettyyn organisaatioon. Tämä ominaisuus on hyödyllinen toiminnallisten yksiköiden määrittämisessä ja organisaatiosi asianmukaisen huolenaiheiden erottamisen kokeilemisessa, kun edistyt pakkaamisen kypsyydessä. Jos kuitenkin valitset tämän lähestymistavan, ymmärrät vain vähän pakattavan metadatan hyödyistä, mukaan lukien lähdekoodiin perustuva kehitys, versioinnin käyttö ja artefaktin vakaus. Sen sijaan saatat todennäköisesti jatkaa tiiviisti yhdistetyn järjestelmän haittoja, mukaan lukien:

• Yksittäiset virhepisteet, jotka aiheuttavat käyttökatkoksia ja suorituskykyongelmia
• Hitaat ja odottamattomat käyttöönotot
• Vaikeat ja monimutkaiset virheenkorjaus- ja vianmääritysjaksot
• Ongelmat, jotka liittyvät skaalaukseen ja suorituskykyyn

Kaikkien pakattavissa olevien Salesforce-järjestelmien päätavoite on irrotettava paketti.

Ota huomioon seuraavat seikat, kun tarkastelet Salesforce-metadatasi erottamista tehokkaiksi paketeiksi:

• Mitä mukautuksia data vs metadata on. Salesforce Platform käsittelee dataa ja metadataa hyvin eri tavalla paketoitavuuteen liittyen. On tärkeää ymmärtää, mitkä organisaatiosi ominaisuudet ovat metadataa tai dataa. Et voi sisällyttää dataa mihinkään pakattuun yksiköön. Kun päätät, mistä aloittaa toimintojen abstraktiointi pakattuun yksiköön, tiimisi täytyy päättää, tulisiko datana säilytetyt mukautukset jättää pakettiin kokonaan pois vai muuttaa ne metadataan perustuvaksi toteutukseksi.
• Miten pakkaaminen vaikuttaa tiimeihin. Salesforce-pakkauksen logistinen todellisuus on, että paketin version tuottaminen ja julkaiseminen vaatii osaamista Salesforce CLI- ja/tai CI/CD-teknologioissa. Tämä tarkoittaa, että alhaisen koodin mukautukset ja ohjelmalliset mukautukset vaativat aikaa ja huomiota henkilöiltä, jotka voivat käyttää pakettiin liittyvää DevOps-teknologiaa. Riippuen siitä, miten tiimisi hallitsee ominaisuuksien toimitusta, pakettien käyttöönotto saattaa hidastaa tai estää organisaation eri tiimejä. Sinun täytyy tunnistaa, voivatko tiimit hallita ominaisuuksien toimitusta pakkauksen kautta, ja tehdä suunnitelma, jolla voit korjata taitojen tai henkilöstöjen aukkoja. Ratkaisut voivat sisältää yhdistetyn ohjelmoinnin käyttöönoton tai CI/CD-töiden toteuttamisen kehitysympäristöille.
• Miten pakkaaminen muuttaa ympäristöstrategioita. Paketteihin perustuvassa kehitysympäristössä aikaiset työt tulisi tehdä luonnosorganisaatioissa. Nämä lähdekohtaiset väliaikaiset kehitysympäristöt mahdollistavat nopeampia ja iteratiivisempia syklejä. Ne tukevat myös tarkempia ympäristöjen käyttöoikeuksia kehitystiimeillesi ja suurempaa erillisyyttä tuotantoympäristöstä. Mitä enemmän paketteillasi on sidonnaisuuksia paketoimattomaan metadataan tai dataan, joka on olemassa vain sandbox- tai tuotantoympäristössä, sitä todennäköisemmin tiimit voivat käyttää luonnosorganisaatioita. Voit ottaa lähdeseurannan käyttöön sandboxeissa salliaksesi lähteisiin perustuvat kehityskuviot ei-luonnosorganisaatioympäristöissä — mutta kehitystiimisi eivät hyödy luonnosorganisaatioiden nopeudesta tai iteratiivisesta nopeudesta.
• Miten paketin versiot liittyvät julkaisuihin. Suunnittele, kuinka usein ja missä vaiheessa kehityspaketin versioinnin tulisi tapahtua. Pakettien versioiden pyyntöjä on rajoitettu (organisaatiokohtaisesti) 24 tunnin välein. Suosittelemme, että versioit paketin vain, kun olet varma, ettei paketin sisältöä tarvitse muuttaa. Sinun kannattaa provisioida paketin versiot, kun laadunvalvontaprosessit on suoritettu. Älä salli kehitystiimien käyttää pakettien luontipyyntöjen onnistumista tai epäonnistumista "testauksina" siitä, miten hyvin he ovat määrittäneet paketin rajat. Voit tehdä tämän yrittämättä versioida paketin artefaktia eri tavoin.
• Mitä ihanteellisen päätilan tulisi tukea. Ihanteellinen pakkausstrategia sallii hallitun ja vakaan Salesforce-julkaisun, joka voidaan kehittää ja toimittaa nopeasti. Liian monen paketin määrittäminen organisaatiossasi voi aiheuttaa monimutkaisuuksia ja pullonkauloja kehitystiimeillesi. Liian modularisoitu organisaatio voi aiheuttaa myös hitaita ja vaikeita julkaisuja. Aloita rakentamalla ja julkaisemalla muutama hyödyllisen paketin versio. Luo jatko-paketteja asteittain. Lopeta pakettien esittely, kun sinulla on yrityksellesi sopiva julkaisutapaus. Refactor-paketit ajan myötä, jos liiketoimintatarpeet muuttuvat tai julkaisun laatu heikkenee. Ideaalinen paketin päättymisaika on subjektiivinen.

Riippumatta siitä, miten päätät määrittää pakettisi, voit versioida vain löysästi yhdistetyn paketin onnistuneesti tehokkaalla riippuvuuksien hallinnalla.

Alla olevassa kuvioiden ja antikuvioiden luettelossa näytetään, miltä Salesforce-pakkauksille sopiva (ja huono) löysä kytkentä näyttää. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen rakentamista tai tunnistaaksesi järjestelmäsi alueet, jotka täytyy uudelleenrakentaa.

Lisätietoja Salesforce-työkaluista, jotka auttavat sinua parantamaan pakkaamista, on kohdassa Composable-työkaluihin liittyvät työkalut.

Riippuvuuksien hallinta tarkoittaa Salesforce-ratkaisun kontekstissa pakettiesi metadatan ja niiden organisaatioiden metadatan välisten suhteiden tunnistamista ja rakentamista, joihin paketit asennetaan. Riippuvuuksien hallinta on tärkeä osa pakettien vakaiden artefaktien kehittämistä.

Riippuvuudet voivat olla ristiriidassa toiminnallisten yksiköiden luomisessa, jotka ovat täysin erillään ja jotka ovat vapaasti yhdistettyjä. Idealissa suunnittelutilassa löysästi yhdistetyllä järjestelmällä ei ole sidonnaisuuksia yksiköiden välillä. Kaikkien riippuvuuksien poistaminen ei kuitenkaan ole käytännöllistä todellisessa maailmassa.

Jos haluat tehdä järjestelmistä lukemattomia ja käyttää liiketoimintaystävällisiä toimintoyksiköitä, sinun täytyy usein tehdä kompromissit järjestelmän yksiköiden täydellisen eristämisen osalta. Pragmaattisemmin Salesforce Platformin vakiotoimintojen tarjoamat ydinpalvelut luovat tärkeitä, netto-positiivisia riippuvuuksia mille tahansa Salesforce-ratkaisulle. Monet sisäänrakennetun skaalattavuuden, suorituskyvyn ja tietoturvan eduista johtuvat siitä, miten syvällisesti ne on integroitu sovellusalustaan. Kun suunnittelet pakattavissa olevia Salesforce-ratkaisuja, on tärkeää muistaa, että pakettien sidonnaisuudet eivät ole luonnostaan huonoja. Riippuvuuksien hallinta on huonoa.

Tehokas riippuvuuksien hallinta Salesforce-pakkauksella tarkoittaa, että kehitys- ja huoltotiimit voivat:

• Aloita uusille projekteille nopeammin ja rajoitetuilla käyttöoikeuksilla
• Kehitä ja testaa muutoksia nopeasti
• Ymmärrä, miten monimutkaisia toimintoja tulisi tarjota pienissä, tarkkoissa sitoumuksissa
• Hallitse julkaisujaksoja ja vähennä järjestelmän ylläpidon/julkaisun käyttökatkoksia
• Ennustettavissa olevat peruuttamattomat haitalliset muutokset missä tahansa ympäristössä

Riippuvuuksien hallinta Salesforcen avulla on melko yksinkertaista:

• Käytä viestejä ja tapahtumia käsitelläksesi tilassa olevien tai tilattomien tietojen hienovaraisia välittämisiä komponenttien välillä.
• Käytä mukautettuja metadatatyyppejä tarjotaksesi dynaamisia suorituksen aikaisia tietoja ja tukeaksesi riippuvuuksien injektiokuvioita.
• Pyydä Apex-kehittäjiä käyttämään abstrakteja tai virtuaalisia luokkia.

Lopuksi sinun täytyy päättää organisaatiossasi sallitut suunnittelukuvioet deklaratiivisessa ja ohjelmallisessa kehityksessä. Tärkeimmät huomioitavat asiat (arkkitehtuurisesti) ovat määrittää missä haluat lisätä monimutkaisempia rakenteita vähentääksesi sidonnaisuuksia ja missä sinun täytyy sallia enemmän sidonnaisuuksia yksinkertaistaaksesi sovellusrakentajan työnkulkuja.

Kun rakennat sidonnaisuuksien hallintastrategioita paketteihisi, ota huomioon pakettiyksiköiden kaksi ensisijaista organisointiperiaatetta: vaakasuora ja pystysuora.

• Vaakasuorat rajat. Vaakasuorassa paradigmassa toiminnot, joita useampi kuin yksi paketti saattaa tarvita, lasketaan vaakasuoraksi kerrokseksi. Vaakasuorista kerroksista tulee yleisten ominaisuuksien lähde, ja niitä käytetään esitetyn sidonnaisuuden kautta. Pakettien tarpeettomien toimintojen minimointi on suositeltavaa riippuvuuksien minimoinnin sijaan.
• Pystysuorat rajat. Pystysuorat paradigmat maksimoivat järjestelmän osien eristämisen ja irrottamisen. Jaettuja toimintoja on rajoitettu, ja samankaltaisia töitä saattaa esiintyä kaikissa yksiköissä. Riippuvuudet on rajoitettu tarkasti pakettiyksiköiden eristämisen maksimoimiseksi.

Huomaa, että tämä ei ole joko/tai päätös. Voit yhdistää pystysuoria ja vaakasuoria paradigmia tarvittaessa. Tavallisesti nopein tapa aloittaa paketin käyttö on luoda vaakasuoria palvelualueita. Kun pakettien sopeutumisen skaala ja monimutkaisuus kasvaa, pystysuorempien yksiköiden abstraktio auttaa yksinkertaistamaan monimutkaisia ympäristöjen määritysprosesseja tai kehittäjien perehdytystä.

Järjestelmä, jossa on esimerkiksi kaksi toiminnallista yksikköä (A ja B), voidaan rakentaa pakettien sidonnaisuuksilla, jotka on järjestetty pystysuorassa, vaakasuorassa ja pystysuorassa.

Riippumatta valitsemastasi pakettien järjestämisen paradigmasta, sinun kannattaa pitää mielessäsi muutama absoluuttinen arvo:

• Älä kopioi metadataa eri paketeissa. Useamman kuin yhden paketin vaatima metadata tulisi poimia yhteen tai useampaan pakettiin, jotka esitetään sidonnaisuuksina.
• Käytä Salesforce Platform -metadatan sisäänrakennettuja sidonnaisuuksia. Sovellusrakentajille Salesforce Platformin tarjoamat sisäänrakennetut palvelut tarjoavat paljon toimintoja, jotka voidaan määrittää nopeasti. Monilla näistä palveluista on sisäänrakennettuja sidonnaisuuksia, jotka vaikeuttavat niiden abstraktiointia alhaisen tason toiminnallisiin yksiköihin. Sinun täytyy ymmärtää tietylle metadatatyypille, mihin se osuu sisäänrakennettujen sidonnaisuuksien alueella, ja käyttää tätä ymmärrystä pakettien sidonnaisuuksien ketjujen määrittämiseen. Älä aloita pakettien sopeutumista yrittämällä pakottaa irrotettavaa yhdistämistä tavalliseen sovellusalustan toimintoon, jossa on paljon sisäänrakennettuja sidonnaisuuksia. Se lisää monimutkaisuutta (ei arvoa), kun saavutat korkean tason ominaisuuksia. Se on myös toinen tapa osua vakiomuotoisiin vs. mukautettuihin anti-kuvioihin. Pakkaa metadataa alalaidasta (vähiten riippuvuuksia) ylös — ja iteroi ajan myötä.
• Valvo sidonnaisuuksien ketjuja. Vältä luomasta pakettien sidonnaisuuksien ketjuja, jotka vaativat kehittäjiä jakamaan muutokset useisiin eri paketteihin kerralla.
• Mieti, mikä sopii lähdekoodin hallintaan. Voit hallita pakettejasi lähdekoodin hallinnassa kahdella eri tavalla. Ensimmäinen on yksi monorepo, jossa paketit on eristetty kansioihin. Toinen on useita säiliöitä, joissa paketit on eristetty omassa säiliössä. Jokaisen lähdestrategian hallitseminen pitkällä aikavälillä on monimutkaista. Kehittäjien perehdytyksen osalta pystysuorat rajat ovat tehokkaampia useissa säiliöparadigmeissa. Vaakasuorat rajat ovat helpommin ymmärrettäviä monorepoksessa. Voit myös yhdistää ja täsmätä strategioita, kun arkkitehtuuri kehittyy.

Alla oleva kuvioiden ja antikuvioiden luettelo näyttää, miltä riippuvuuksien hallinta näyttää Salesforce-paketeilla. Voit käyttää niitä vahvistaaksesi suunnittelusi ennen rakentamista tai tunnistaaksesi järjestelmäsi alueet, jotka täytyy uudelleenrakentaa.

Lisätietoja riippuvuuksien hallintaan tarkoitetuista Salesforce-työkaluista on kohdassa Yhdistettävissä olevat työkalut.

Seuraava taulukko näyttää valikoiman kuvioita, joita haluat etsiä (tai rakentaa) organisaatiossasi, sekä vasta-kuvioita, joita haluat välttyä tai joilla haluat korjata.

✨ Tutustu pakkaamista koskeviin kuvioihin kohdasta Pattern & Anti-Pattern Explorer.

Auta meitä pitämään Salesforce Well-Architected ajan tasalla. Tee kysely saadaksesi palautetta tästä sisällöstä ja kerro meille, mitä haluat nähdä seuraavaksi.