Hogyan néz ki egy rendszer, amikor egy csapat egyszerre tervez a sebesség, a biztonság és a változtathatóság szempontjából?
Az attribútumvezérelt tervezés (Attribute Driven Design, vagyis ADD) úgy válaszol erre, hogy a rendszert kisebb részekre bontja azoknak a minőségi céloknak az alapján, amelyek a legfontosabbak. Átváltja a tág igényeket konkrét szoftverelemekre, majd megmutatja, hogyan kell ezeknek együttműködniük.
Kezdje a vezérlő attribútumokkal
A szoftvertervezés egy valódi üzleti igénnyel kezdődik. Egy fizetési folyamat erős biztonságot igényelhet. Egy belső automatizálási eszköz könnyű módosíthatóságot igényelhet. Egy AI-szolgáltatás gyors válaszidőt és egyértelmű hibakezelést igényelhet.
Az ADD ezeket az igényeket kezelési tényezőként kezeli. Ezek a tényezők alakítják ki, hogyan bontják szét a rendszert. A cél nem először dobozokat rajzolni. A cél eldönteni, mely minőségeknek kell érvényesülniük, amikor a rendszer a valós világban fut.
Ezért tűnik gyakorlatiasnak az ADD. Korlátozásokkal kezd, nem díszítéssel. Egy ügyfélportál terve eltér egy kötegelt jelentéstételi feladat tervétől, mert a minőségi követelmények mások.
Bontsa le a rendszert lépésről lépésre
Miután ismertek a fő iránytűk, a tervező egy-egy rendszer elemre alkalmaz egy tervezési koncepciót. Ez a koncepció származhat egy hivatkozási architektúrából vagy egy ismert mintából. A kulcs az, hogy adaptálják, nem másolják. Egy általános legjobb gyakorlat irányíthatja a munkát, de a végső forma illeszkednie kell a jelenlegi rendszer üzleti szabályaihoz, műszaki korlátaihoz és minőségi céljaihoz.
Itt történik a lebontás. Egy nagy elemet kisebb elemekre bontanak, amelyek mindegyike egyértelmű feladatot lát el. Egy rész kezelheti a felhasználói bemenetet. Egy másik validálhatja az adatokat. Egy másik hívhat egy külső szolgáltatást. Egy másik tárolhat eseményeket vagy rekordokat.
Egy egyszerű példa segít. Képzeljen el egy online rendelési rendszert. A rendelésfelvételi szolgáltatás lebontható kérelemkezelőre, validációs komponensre, árazási komponensre és rendelés-tároló komponensre. Minden rész létezik, mert a tervezés egyértelmű tulajdonjogot, könnyebb módosíthatóságot vagy jobb kontrollt igényel a hibakezelés felett. A szétválasztást az attribútumok hajtják, nem a szokás.
Ez a lépés a módszer középpontja. Itt válik az absztrakt cél szoftverstruktúrává.
Dokumentálja az eredményt elegendő részletességgel
Miután a tervezést alkalmazták, a struktúrát le kell írni. Új komponensekhez nevek, felelősségek és egyértelmű határok kellenek. Felül kell definiálni a interfészeiket, valamint a szerződéseket, amelyeket használnak egymással való kommunikációhoz.
Ezek a szerződések fontosak, mert a szoftver ritkán él egyedül. Egy frontend beszél egy backenddel. Egy szolgáltatás beszél egy másik szolgáltatással. Az események adatokat szállítanak egy soron vagy üzenetsínön keresztül. Minden átadásnál megállapodásra van szükség a mezőkről, verziókról és kötelező értékekről. Ha ez a megállapodás homályos, a rendszer törékeny lesz.
Szekvenciadiagramok is hasznosak ebben a szakaszban. Megmutatják a hívások sorrendjét egy fontos üzleti folyamatban. Például egy bejelentkezési folyamat, egy fizetési folyamat vagy egy rendelés-létrehozási folyamat leírható lépések sorozataként. Ez a csapatoknak közös nézetet ad a futási viselkedésről, ami gyakran ott rejlenek a rejtett tervezési hibák.
A gyakorlatban ez a dokumentáció nem formalitás. A tervezés része. Enélkül egy lebontás jól nézhet ki egy fehér táblán, és kudarcot vallhat a megvalósítás során.
Ellenőrizze, mit változtatott a tervezés
Egy jó lebontás nem egy rajzzal ér véget. Tesztelni kell azon vezérlő tényezőkkel szemben, amelyek formálták azt.
Egy ellenőrzés a kockázat. Egy új architektúrális választás új gyengeségeket vezethet be. Egy felhős sor javíthatja a leválasztást, de hozzáadhat meghibásodási módokat, amelyekre figyelmet kell fordítani. Egy új biztonsági réteg megkeményítheti a hozzáférést, de hozzáadhat komplexitást az integrációs csapatok számára. A tervezésnek láthatóvá kell tennie ezeket a kockázatokat.
Egy másik ellenőrzés a költség. Ez magában foglalja az infrastruktúrát, a licencet, az üzemeltetést és a hosszú távú karbantartást. Sok kis szolgáltatású rendszer lehet elegáns papíron, de drága futtatni, ha minden részhez külön monitorozás, telepítés és támogatás szükséges. A költség az architektúra része, nem utólagos gondolat.
Egy harmadik ellenőrzés az új vezérlő tényezők. Egy tervezési döntés feltárhat egy új igényt, amely eddig nem volt egyértelmű. Egy specifikus eszköz kiválasztása felfedhet egy biztonsági szabályt. Egy üzenetformátum kiválasztása felfedhet egy verziókezelési problémát. Ezek az új vezérlő tényezők a backlogba tartoznak, így a következő iteráció megoldhatja őket.
A negyedik ellenőrzés az áldozat-elemzés. Minden tervezési választás ad valamit és vesz el valamit. Gyorsabb válasz több infrastruktúrát jelenthet. Erősebb biztonság kevesebb használhatóságot jelenthet. Több elkülönítés több integrációs munkát jelenthet. A tervező feladata, hogy ezt az áldozatot nyilvánvalóvá tegye.
Kapcsolódó: A SketchUp Pro és a Vectorworks vezeti a Mac architektúra szoftverek piacát
Miért fontos ez az alkalmazott AI és automatizálás számára
Az ADD hasznos az AI és automatizálási munkában, mert ezek a rendszerek gyakran a határokon buknak meg. Egy modell működhet, de az adatfolyam gyenge lehet. Egy automatizálási folyamat lehet gyors, de a kivételkezelési útvonal törékeny lehet. Egy lebontott tervezés segít a csapatoknak elválasztani a modell logikáját, az orchestrációt, a validációt, a audit naplózást és az emberi felülvizsgálatot.
Ez az elválasztás fontos az vállalati környezetben. Segít a csapatoknak látni, mi változhat gyakran és mi maradhat stabil. Segít nekik szerződéseket meghatározni a bemenet, a kimenet és az átadási pontok körül. A gyakorlatban ez megkönnyíti a rendszer értelmezését, amikor az üzleti folyamat megváltozik.
Az EuroOp LLC ezt általános mérnöki mintának tekinti. Az érték nem több doboz rajzolásában rejlik. Az érték abban rejlik, hogy a megfelelő dobozhatárokat használják a megfelelő minőségi célokra.
Egy olyan olvasó, aki megérti az ADD-t, most jobban kérdezhet egy szoftverelemet nézve: milyen üzleti minőség alakítsa a szétválasztását, és milyen szerződéseknek kell érvényesülniük a szétválasztás után? Ez az eltolódás az architektúrát találgatásból egy diszciplinált módszerré teszi a szoftverelemek lebontására. Az EuroOp Insights ezt ugyanazt a mintát használja, egyik alkalmazott kutatás-fejlesztési leckét a másik után, hogy a gyakorlati leckét közel tartsa az ahhoz a mérnöki munkához, amely létrehozta.
Kapcsolódó: Az SAP S/4HANA vezeti az vállalati eszközkezelő szoftverek piacát · Az üzleti AI-infrastruktúra skálázásának öt alapvető eleme