Next.js vagy htmx + Rust. Mikor melyiket válassza
Hasonlítsa össze a Next.js, valamint az Axum, Askama és htmx megoldást böngészőállapot, szerződések, gyorsítótár, üzemeltetés és átadás szerint.
Tervezési minták a gyakorlatban. Mikor segítenek és mikor bonyolítanak
A tervezési minta nem a szakmai rang bizonyítéka. Olyan megoldás neve, amely egy adott problématípusnál többször bevált. Ha a probléma nincs jelen, a minta csak fájlokat, interfészeket és új fogalmakat ad a rendszerhez valódi kockázatcsökkentés nélkül.
Üzleti szoftver tervezésekor ezért először azt vizsgáljuk, mi fog változni, ki felel érte, és minek kell stabilnak maradnia. A válasz vezethet Strategy, Adapter, Factory mintához vagy egy közvetlen függvényhez.
A várható változásból induljon ki, ne a minta nevéből
Általában a várható változást elkülönítő legkisebb absztrakció a jó választás.
Egy stabil szabály
Maradjon közvetlen függvény.
Változó algoritmus
Fontolja meg a Strategyt.
Idegen interfész
Válassza le Adapterrel.
Több létrehozási út
A Factory elrejtheti az összeállítást.
Az egyszerű kód nem kezdetleges
Vegyünk egy szállítási díjszámítást. Az első verzió személyes átvételt és egy futárt kezel. Két feltétel egy függvényben könnyebben érthető, mint egy osztályhierarchia. A bemenet, a szabály és az eredmény együtt látható.
A helyzet akkor változik, amikor a szabályok egymástól függetlenül fejlődnek. Az egyik futár súly, a másik régió alapján számol. A szerződéses ügyfelek külön feltételeket kapnak. A függvénynek több, egymástól független oka lesz a módosításra, így egy változtatás más útvonalakat is veszélyeztet.
A jó tervezés nem a sorok számára reagál. A független változási okokat figyeli. Ötven stabil sor egyszerűbb lehet tíz olyan sornál, amelyet hetente különböző üzleti okokból írnak át.
A Strategy leválasztja a változó szabályt
A Strategy akkor illik a problémához, ha a feladat azonos marad, de az algoritmus cserélhető. Továbbra is szállítási árat számítunk, csak a módszer változik futár vagy szerződés szerint.
type DeliveryQuote = (order: Order) => Money;
const quoteDelivery = (order: Order, quote: DeliveryQuote): Money =>
quote(order);
A Strategy nem feltétlenül osztály. TypeScriptben gyakran elég egy típus és néhány tiszta függvény. A rendelés nem ismeri a futár árlistáját, a kalkulátor pedig nem tudja, honnan érkezett a rendelés. Új szabályt a meglévő algoritmusok módosítása nélkül adhatunk hozzá.
A minta rossz választás, ha csak egy stabil számítás létezik, vagy minden változat sok közös módosítható állapotot használ. A kis strategy fájlok ilyenkor csak áthelyezik a feltételeket. Előbb a valódi határt kell megtalálni.
Az Adapter védi a domént az idegen modelltől
Egy ERP, fizetési szolgáltató vagy futár saját neveket, adattípusokat és hibákat hoz. Ha ezek közvetlenül az alkalmazás magjába kerülnek, a domén a szállító nyelvén kezd beszélni. Egy API-frissítés ezután rendeléseket, számlákat és felhasználói felületet érint.
Az Adapter az idegen felületet a saját rendszer kis szerződésére fordítja. A domén reserveStock műveletet kérhet akkor is, ha az egyik ERP készletmozgást, a másik tételfoglalást kínál. A különbség az integrációs határon marad.
Ez a határ a tesztelést is javítja. A doméntesztnek nincs szüksége hálózatra vagy szolgáltatói tesztfiókra. A saját szerződés szerinti viselkedést ellenőrzi. Külön integrációs teszt bizonyítja a kérések, válaszok és hibák helyes fordítását.
Az Adapter nem általános fiók a rendezetlenségnek. Ha minden mezőt egy az egyben nevez át, miközben a külső API stabil, kevés értéket ad. Haszna az idegen modell és a saját domén közötti jelentésbeli távolsággal nő.
A Factory az összeállítást rejti el
A Factory akkor segít, amikor egy objektum vagy folyamat összeállítása a bemenet típusától függ. Egy PDF-számla feldolgozó OCR-t, ellenőrzést és könyvelési leképezést igényelhet. Egy szerződés más kinyerőt és más ellenőrzéseket használ.
A hívónak nem kell ismernie minden függőség sorrendjét. Egy dokumentumtípushoz kér feldolgozót. A Factory összeállítja, majd közös szerződésen keresztül visszaadja.
Az üzleti döntés nem tűnhet el egy sokágú Factory belsejében. A technikai elemek kiválasztása az összeállítás része. Annak eldöntése, hogy egy számla automatikusan könyvelhető-e, doménszabály. Láthatónak és külön tesztelhetőnek kell maradnia.
Ugyanaz a funkció, más változási pont
A minta akkor hasznos, ha csökkenti a következő valós módosítás hatókörét.
Előtte
Egy szolgáltatás ismeri az árakat, szolgáltatókat és dokumentumformátumokat.
Szétválasztás után
A doménát kis interfész védi, a változás részlete a határ mögött marad.
A mintának szűkítenie kell a következő változást
Kódellenőrzéskor három kérdés segít. Meg tudunk nevezni egy konkrét várható változást? A minta egy határ mögött tartja azt? Az eredmény érthetőbb annak, aki nem ismeri a döntés történetét?
Ha nem, az absztrakció valószínűleg túl korán érkezett. A kódnak nem kell minden elképzelhető jövőt kezelnie. A termékből, szerződésekből és működésből következő változásokra kell felkészülnie.
A minták együtt is működhetnek. Az Adapter saját interfészt ad a doménnek. A Strategy tartja a változó szabályt, a Factory pedig összeállítja a függőségeket. Ez csak akkor indokolt, ha minden elem más határt véd. Ha három név ugyanazt a feltételt írja le, a terv túl nagy.
Mit kérdezzen a megrendelő
Egy cégvezetőnek nem kell osztálydiagramot ellenőriznie. Azt kell tudnia, hogy egy új fizetési mód vagy ERP-csere az egész rendszert érinti-e. A műszaki vezetőnek látnia kell a szabály helyét, szerződését és viselkedést védő tesztjét.
Az egyedi szoftverfejlesztésben a technikai határt valós üzleti változáshoz kötjük. A következő írás ugyanezt a gondolkodást alkalmazza a moduláris monolit és a mikroszolgáltatások választására. Az AI fejlesztői munkára gyakorolt hatásáról az emberi ellenőrzésről szóló cikkünk ír.
A legjobb minta a napi munkában szinte eltűnik. A következő módosításnak egyértelmű helye van, a teszt célja világos, a rendszer többi része pedig nem tud a változásról. Bevezetés előtt még egyszer érdemes megkérdezni, hogy egy közvetlen függvény nem tartaná-e érthetőbben ugyanazt a változási teret. A név önmagában nem érték. A kisebb módosítási kockázat az.
Érdemes röviden rögzíteni a döntést is. Írjuk le a problémát, a várt változást és azt a határt, amelyet a minta véd. Így egy későbbi fejlesztő nemcsak a szerkezetet látja, hanem az okot is. Ha a feltételezés megszűnik, a minta eltávolítható.
Egy kis próbamódosítás gyors visszajelzést ad. Adjunk hozzá még egy futárt vagy cseréljünk ki egy szolgáltatót egy külön ágon. Ha a változás a kijelölt interfész mögött marad, a határ működik. Ha minden réteget módosítani kell, az ismert mintanevek csak elfedték a kapcsolódást.
Források és bizonyítékok
Hogyan készült a cikk
Maroš Bednár AI-támogatással készítette a kutatást és a nyelvi szerkesztést. A szakmai következtetéseket, példákat és a végleges szöveget ellenőrizte és jóváhagyta.
A Rise.sk alapítója és műszaki vezetője. Webalkalmazásokat, adatrendszereket és automatizálást tervez és szállít; szoftverdöntésekről, AI-ról és digitális szolgáltatásokról ír.
- Szoftverarchitektúra
- AI-automatizálás
- Adatrendszerek
Következő olvasmány
Szoftverszállító átvilágítása. Biztonság, integráció és tulajdon
Ellenőrzőlista biztonságról, integrációkról, adatkezelői szerepekről, tulajdonról, támogatásról és kilépésről szerződéskötés előtt.
Hogyan válasszon szoftveres és technológiai partnert
Gyakorlati útmutató a követelményekhez, a beszállítók összehasonlításához, a bizonyítékok ellenőrzéséhez és a közös döntéshez.