Tuo selkeyttä monoliittiisi rajatuilla yhteyksillä

Katso video tästä ElixirConf 2017-keskustelusta alla

monoliittiset sovellukset ovat loistavia, kun aloitat yrityksen rakentamisen, mutta ajan edetessä niitä on vaikea ylläpitää. Näistä koodebaaseista tulee kasvaessaan helposti isoja Mutapalloja.

rakennettaessa suuria sovelluksia kehyksiin, kuten kiskoihin, jo ne ylikokoonpanon suunnitteluperiaatteet, jotka tekivät kiskoista niin ilon käyttää, alkavat tulla tielle, kun sovellus laajenee. Sinäkin saatat kokea samoja kipuja, jos:

• Refaktorointi on vaikeaa ja työlästä, koska menetelmät ja luokat riippuvat liian monista muista luokista
• sinulla on alati kasvava lista liikekohteita, joita on vaikea pitää päässäsi. Itse asiassa kukaan ei näytä ymmärtävän järjestelmää yhtenäisenä kokonaisuutena
• koodin muuttaminen yhdellä koodin alueella johtaa odottamattomiin ja tahattomiin sivuvaikutuksiin koodin muilla alueilla, koska on helppo kutsua maailmanlaajuisia palveluita ja esineitä

viimeisessä keskustelussamme keskustelimme yhdessä yritysasiantuntijoiden ja kehitystiimisi kanssa kaikkialla käytettävän kielen kehittämisestä auttaaksemme tiimiäsi työskentelemään tiiviimmin yhdessä. Tänään aiomme rakentaa sitä ottamalla käyttöön uusia Domain-Driven Design (DDD) – työkaluja. Sitten, otamme käyttöön uuden kansiorakenteen rails Sovellukset, valmistelee ne tulevaisuudessa, jossa sovellus on vähemmän kytketty ja yhtenäisempi. Aloitetaan!

Let ‘ s talk domains

DDD: n keskeinen periaate on, että rakentamasi ohjelmiston tulee heijastaa tarkasti sen rakentavan organisaation (liiketoiminnan) toimialaa. Näin, meidän täytyy tehdä joitakin kotitehtäviä ymmärtää liiketoiminnan verkkotunnuksen ohjelmiston.

toimialue on se, mitä yritys tekee ja miten se sen tekee.

Kerrataanpa Delorean esimerkki aiemmasta virasta. Siinä yhtiötä markkinoidaan aikamatkamatkojen Uberina. Näin ollen sen” valta-alue “(“mitä se tekee”) on aikamatkailua. Myös Domain on “miten”, miten se tekee sen – tekemällä yhteistyötä kuljettajien, jotka omistavat aika-traveling Delorean ajoneuvojen matkustajien kanssa, jotka haluavat tehdä aikamatkustuksen matkoja.

saadakseen enemmän vivahteita liike-elämässä, DDD esittelee toisen käsitteen, nimeltään aliverkkotunnus:

aliverkkotunnus edustaa yrityksen pienempiä ryhmiä tai yksiköitä, jotka tekevät päivittäistä yhteistyötä liiketoiminnan tavoitteiden saavuttamiseksi.

Delorean on jaettu useisiin joukkueisiin seuran sisällä. Katsotaan, mistä he ovat vastuussa.:

	Trip Platform team	Finance Operations team
tehtävä	suunnitella ja tukea järjestelmiä, joilla reittimatkoja ja kuljettajien ja matkustajien välisiä yhteyksiä	hallita järjestelmiä, joissa on mukana rahoituslaitoksia ja luottokorttien käsittelijöitä
velvollisuudet	Yhdistä matkustajat kuljettajiin ohjaa kuljettaja seuraavaan määränpäähänsä ilmoita matkustajille saapuvista kuljettajista ilmoita kuljettajille uusista matkustajista	Process payments to drivers Maintain system-wide transaction history for auditing Build financial reports Process credit card charges to passengers

kumpikin näistä kahdesta ryhmästä animoi liiketoimintavastuun eli aliverkkotunnuksen. Nimetäänpä ne Kimppakyytikokemukseksi ja verkkokaupaksi.

nyt meillä on yleiskuva liiketoiminnan ja kaksi sen yksikköä, jotka auttavat sitä toimimaan jokapäiväisessä. Verkkotunnus ja aliverkkotunnukset ovat tapoja mallintaa yrityksesi ongelmatilaa-ja miten se toimii näiden roolien täyttämiseksi. Mahdollisuudet ovat, yrityksesi org kaavio vastaa tarkasti aliverkkotunnukset yrityksesi. Reaalimaailmassa rajaukset voivat olla epäselvempiä-tiimit voivat olla vastuussa useista, päällekkäisistä aliverkkotunnuksista.

täytetäänpä tämä kaavio muutamalla DeLorean-yrityksen aliverkkotunnuksella:

• asiakastuen aliverkkotunnus: asiakastuen lippujen ratkaiseminen sähköpostitse
• markkinoinnin aliverkkotunnus: managing marketing email campaigns and marketing coupon codes
• Identity subdomain: How the system tracks each user and his / her identification information

rajatut kontekstit ratkaisuavaruudessa

tämä edessämme oleva kaavio kuvastaa nyt yrityksen liiketoiminnan tavoitteita jaettuna loogisiin yksiköihin, jotka (toivottavasti) toteuttavat tavoitteensa reaalimaailmassa. Nyt aiomme overlay ohjelmistojärjestelmät, jotka saavuttavat nämä tavoitteet tämän kaavion. Näitä ohjelmistojärjestelmiä kuvataan rajatuissa yhteyksissä:

rajattu asiayhteys on järjestelmä, joka täyttää reaalimaailmassa liiketoiminnan tavoitteet.

kaikkia ohjelmistojärjestelmiämme (kuten verkkopalvelu tai verkkosovellus), jotka toimivat konkreettisina instansseina reaalimaailmassa, pidetään rajattuina Asiayhteyksinä.

teknisesti ottaen DDD-puheessa rajattu asiayhteys on toimialueen sisäinen tietty raja, jota sanastosi Ubiquitous – kielestäsi voi vain soveltaa-ajatus on, että eri Aliverkkotunnuksilla voi olla kilpailevia tai ristiriitaisia termien määritelmiä. Tässä viestissä ei käsitellä tarkemmin rajatun asiayhteyden kielellisiä vivahteita. Lisätietoja on Martin Fowlerin selityksessä rajatuista yhteyksistä.

nyt tapahtuu niin, että Deloreanissa kaikki nämä aliverkkotunnukset toteutetaan yhdessä järjestelmässä – yhdessä isossa Mutakiskojen Monoliitissa. Piirrämme sinisen ruudun aliverkkotunnusten ympärille, joiden toiminnot Ohjelmisto toteuttaa. Tässä tapauksessa aloitamme edellä mainitulla Rails monolithilla.:

koska se on monoliitti, se periaatteessa tekee kaiken – ja niin tässä, se syö kaikki muut aliverkkotunnukset kaaviossa.

ei unohdeta – meillä on muutama muu ohjelmisto, jota emme ole täällä mallintaneet. Entä kaikki mukavat kolmannen osapuolen integraatiot, joita yritys käyttää? Nämäkin ovat ohjelmistojärjestelmiä. Piirrämme ne sinisiksi laatikoiksi.

muuten-mitä olemme piirtäneet tähän on Kontekstikartta-kaavio, joka sekoittaa liiketoiminnan tavoitteet ja konkreettisia toteutuksia ohjelmistojen. Se on hyödyllinen arvioitaessa maan oman ohjelmiston järjestelmien ja visualisoida riippuvuuksia ryhmien välillä.

now, this is reasonable and clean, but we live in the real world, and real world software Harly comes out looking consistent and coherent. Jos olet rakentanut Rails-sovelluksen sen out-of-the-box-käytäntöjen mukaisesti, sovelluksestasi puuttuu sisäisesti ryhmittymät, jotka ovat tarpeen sovelluksen visualisoimiseksi sen komponenteissa. Todellisuudessa DeLoreanin koodebaasi näyttää enemmän tältä.:

pointti on-Rails ei pakota mitään organisatorisia rajoitteita meidän ohjelmistojärjestelmät-mikä tarkoittaa, että loogiset liiketoimintayksiköt (meidän aliverkkotunnukset), jotka viittaavat irrotettu rajapinnat – ei toteutunut koodi, mikä johtaa sekaannusta ja monimutkaisuutta vuosien varrella.

suuri idea: Järjestä Rails-koodi moduuleiksi yritystunnuksittain

vaikka sovelluksesi Ruby-luokat todennäköisesti elävät maailmanlaajuisessa nimiavaruudessa, ne voidaan helposti nyppiä moduuleiksi. Tavoitteenamme on luoda loogisia domain-koodiryhmiä, jotka voidaan eristää itsenäisiin komponentteihin.

itse asiassa yksi Domain-ohjattujen mallien tavoitteista on yksi-To-one-kartoitus aliverkkotunnuksesta rajattuun kontekstiin.

OK, mitä tämä tarkoittaa? Katsotaanpa saada joitakin suosituksia, yhdessä esimerkkejä.

Käännä kansiorakenteet tasaiseksi toimialakohtaiseksi ryhmittelyksi

saatat muistaa, että seuraavat Rails-konventiot johdattavat meidät kansiohierarkioihin, jotka ryhmittelevät luokat roolien mukaan:

siirretäänpä kaikki uuteen hakemistorakenteeseen: Let ‘ s ryhmä kuin toiminnallisuus verkkotunnuksen, sen sijaan. Aloitamme ensimmäisellä muunnelmalla, jota kutsun tasaiseksi verkkotunnuspainotteiseksi ryhmittelyksi.

moduloi luokat

seuraavaksi haluat moduloida luokat siitä, mitä ne olivat ennen. Koska Ajuriluokka kuuluu Kimppakyytitoimialueeseen, lisäämme sen Kimppakyytimoduuliin:

haluat tehdä tämän jokaiselle luokalle, jonka siirrät app/domains flat-hakemistorakenteeseen.

Viitemallit koko luokkanimen mukaan

lisäksi sinun on muutettava ActiveRecord-malliyhdistelmäsi viitataksesi luokkaan sen täyden moduloidun polun kautta:

pidä ohjaimet ajan tasalla siitä, mistä löydät niiden uudet moduloidut näkymät

sinun on myös lisättävä tämä pieni bitti, jotta reitit ohjaimesta tietävät, mistä etsiä näkymiä:

tässä on se siisti juttu: sinun ei tarvitse siirtää kaikkia koodejasi kerralla. Voit valita yhden pienen verkkotunnuksen sovelluksessasi, kypsimmän alueen koodin tai alueen, joka sinulla on paras ymmärrys ympärillä, ja alkaa siirtää sen huolenaiheita yhteen verkkotunnuskansioon, kaikki jättäen olemassa olevan koodin lepoon, kunnes se on valmis liikkumaan.

nyt olemme ottaneet pieniä askeleita arkkitehtuurisen selkeyden saavuttamiseksi sovelluksessamme. Jos katsomme nyt, meidän modulaarinen kansiorakenteet ovat auttaneet meitä ryhmitelty koodi näin:

konepellin alla sovelluksemme voisi näyttää enemmänkin tältä:

mikä toimii hyvin tällä lähestymistavalla?

1. jokaisessa tiedostohakemistossa on vähemmän melua – ryhmittelemällä kuten tiedostot toimialueen spesifisyyden mukaan, löydämme luonnollisen organisatorisen pisteen
2. kussakin toimialueen kansiossa pysyvät entiteetit ovat hyvin yhtenäisiä-ne todennäköisesti luonnollisesti pyrkivät kommunikoimaan keskenään ja esiintyvät luonnollisesti toistensa kanssa
3. entiteetit, jotka eivät kuulu yhteen, on nyt erotettu (looser – coupled)
4. jos sinulla on engineering tiimit, jotka työskentelevät aliverkkotehtävissä, nämä insinöörit voivat nyt työskennellä Virtaviivaisemmin, eristyneemmin. Löyhempi kytkentä antaa näille tiimeille mahdollisuuden tehdä muutoksia luottaen siihen, että ne eivät ota käyttöön regressioita tai yhdistä ristiriitoja takaisin codebase
5. vaihe on nyt asetettu pitkällä aikavälillä alkaa siirtää kunkin verkkotunnuksen kansioita itsenäiseen ohjelmistopalveluun (lisää siitä tulevassa blogikirjoituksessa)

jos haluat lisäohjeita tähän kansiorakenteeseen, olen kehittänyt esimerkkisovelluksen, joka esittelee tämän toimialueen suuntaisen kansiorakenteen: http://github.com/andrewhao/delorean. Katso ja kerro, mitä mieltä olet.

mitä olemme oppineet?

yhteisessä ajassamme opimme verkkotunnuksia ja aliverkkotunnuksia ympäröivistä domain-pohjaisista suunnittelukonsepteista. Opimme visualisoimaan ohjelmistojärjestelmämme rajattuina Asiayhteyksinä Kontekstikartalla, joka näytti meille järjestelmän alueet, jotka kuuluvat yhteen yhtenäisinä osina.

päättyen käytännön huomautukseen, havainnollistimme, miten Rails-tiedostot ja-kansiot voitiin “kääntää ylösalaisin” ja määritellä uudelleen domain-first-ryhmityksiksi.

seuraavassa viestissäni jatkamme keskustelua tulevassa blogikirjoituksessa siitä, miten voimme edelleen erottaa verkkotunnuspainotteisen Rails-koodimme verkkotunnustapahtumien kanssa ja lopulta tehdä tiemme mikrospalveluiden maahan.