iKonekt
Buksan ang console

Para sa mga grupo at maramihang brand

Maraming kumpanya, isang install, walang pinagbabahaging customers

Karaniwang dalawang beses itong sinosolusyunan ng mga grupo nang mali: limang magkakahiwalay na install at limang magkakahiwalay na lahat, o isang install at isang marangal na pangako na palaging tama ang pag-filter ng application. Ang una ay magastos. Ang ikalawa ay isang pangako, at ang mga pangako ay hindi security model.

Kung hawak mo ang higit sa isang kumpanya — isang holding na may mga subsidiary, isang franchise, dalawang brand na nakatutok sa magkaibang merkado, isang agency at ang bagong itinayo ng agency — alam mo na ang hugis ng problema. Nagbabahagi ang mga brand ng mga tao, tooling at finance department. Hindi sila nagbabahagi ng customers, at hindi dapat mukhang nagbabahagi sila.

Pinapatakbo ng iKonekt ang lahat ng ito mula sa isang install, at ang paghihiwalay sa pagitan nila ay pinapanatili ng database at hindi ng code. Akademiko itong tunog hanggang sa dumating ang araw na hindi na.

Bakit mahalaga ang layer

Ang application-level filter ay isang pangungusap sa isang query. Gumagana ito habang bawat query na isusulat pa ay naglalaman nito — kasama ang isinulat nang nagmamadali, ang isinulat ng bagong developer, at ang isinulat para sa report na isang beses lang talagang gagamitin.

Ilipat mo ang hangganan sa database at babaliktarin ang matematika. Tumatakbo ang patakaran sa bawat read at bawat write, sa ilalim ng lahat. Ang query na nakalimutan ang kumpanya ay hindi nagbabalik ng maling mga row; walang ibinabalik. Ang failure mode ay nagiging blangkong screen at nalilitong developer, na siyang tamang failure mode.

Ang blangkong screen ay feature. Mas gugustuhin naming ipaliwanag ang blangkong screen sa isa naming sariling engineer kaysa ipaliwanag ang listahan ng customers sa dalawang kliyenteng hindi inaasahang magkikita.

Isang installKada kumpanya
  • 1Mga customer & threadNaka-scope. Ang seller sa brand A ay hindi makaaabot sa mga sa brand B, sa pamamagitan ng disenyo at hindi ng configuration.
  • 2Mga claim sa isang customerAng "mayroon na kaming account na ito" ay isang lock na hawak kada kumpanya — kaya dalawang brand ang maaaring parehong magtrabaho sa iisang merkado nang hindi nagbabanggaan.
  • 3Mga prompt & settingSarili ng bawat kumpanya ang ina-edit nila. Ang iisang lugar na naibahagi ito noon ay isang bug, at ito ang bug na pinakapinagmamalaki ng sistemang itong nahanap.
  • 4Mga partner programmeIsang module kada kumpanya, hindi isang pandaigdigang minamana ng lahat.

Hangganang ipinatupad sa ilalim ng application

Ano talagang nababahagi ng isang grupo

Ang paghihiwalay ay hindi isolation para lang sa isolation. Ang mga bagay na sulit ibahagi sa buong grupo ay sadyang ibinabahagi, at karamihan sa mga ito ay ang mga nakakabagot — na tama lang, dahil doon nakatira ang dobleng gastos:

  • Isang install na papatakbohin at ia-update. Isang deployment, isang set ng credentials na aalagaan, isang bagay na pananatilihing naka-patch.
  • Isang koponan ng mga tao, nakaiba-ibang sombrero. Maaaring magtrabaho ang isang tao sa higit sa isang kumpanya; ang hindi niya maaaring gawin ay makakita ng pareho nang sabay-sabay sa pamamagitan ng query na nakalimutang magtanong.
  • Isang set ng gawi. Ang paraan ng pag-assign ng lead, ang paraan ng pagsulat ng note, ang paraan ng pag-abot ng trabaho sa invoice — natutunan nang isang beses, inilalapat kahit saan, na pinaikli ang onboarding sa mga isang umaga.
  • Isang relasyon sa natitirang pamilya. castomAPI sa ilalim, parehong account, parehong mga connector — naka-configure kada kumpanya kung saan mahalaga.

Ang tanong na laging pangalawang itinatanong ng isang grupo

"Makakapag-report ba kami sa lahat ng ito?" Oo — mula sa sariling pananaw ng grupo, sadya at malinaw, at hindi bilang side effect ng butas na hangganan. Ang pagkakaibang ito ang buong disenyo: ang pagtawid sa linya ay kailangang gawa ng isang taong sadyang gumawa nito, na may awtoridad upang gawin ito. Hindi ito kailanman maaaring mangyari sa aksidente dahil lang sa ligaw na identifier.

At ang tanong nilang pangatlo: "ano ang mangyayari kung ibenta namin ang isa sa mga brand?" Ang hangganang pinapanatili ng database ay hangganan ding maaaring kunan ng malinis na kopya. Hindi ito pagkakataon lang — ang paghihiwalay at portability ay iisang katangiang tinitingnan mula sa dalawang magkaibang pulong.

Sa ilalim ng sahig

Ano ang humahawak sa linya, tiyak

Hindi paghahangad, listahan. Kung hindi kayang gawin ng isang supplier ang listahang ito tungkol sa sarili nilang produkto, sulit itong mapansin.

26

Mga table na may dala nilang kumpanya, na ang check ay pinilit na naka-on at hindi lang available.

72

Mga patakaran, isinusulat nang isa-isa upang nabasa ng isang tao ang bawat isa, at hindi ginawa sa isang loop.

942

Mga test, pinapatakbo laban sa database na muling binubuo mula sa wala sa bawat pagbabago.

0

Mga default na kumpanya. Ang request na walang scope ay nagtatapon bago pa umabot sa data — walang fallback na makakalimutang i-disable.

Paano binubuo ang paghihiwalay →

“Limang kumpanya, limang install, limang invoice mula sa iyo.”

Isang install. Limang hangganan na pinapanatili ng database.

Iisang mga tao, iisang mga gawi, iisang platform — at hindi kahit isang shared na customer. Ang pagtawid sa linyang iyon ay dapat nangyari dahil sinadya ng isang tao, hindi dahil sa isang identifier na nadamay lang nang aksidente.

Paano binubuo ang paghihiwalay →