Kwa nini Mifumo ya Kikoa (Domain Models) ni Muhimu Zaidi katika Enzi ya AI

Usanifu wa programu (Software architecture) mara nyingi ni mdahalo usio na mshindi. Unajenga mfumo mmoja. Huwezi kamwe kujenga mbadala wake chini ya hali zilezile. Hii inafanya kila uamuzi usiweze kuthibitishwa kuwa umekosea (unfalsifiable). Mfumo unapofeli, watu huwalaumu kikoa (domain) au timu. Hawalaumi usanifu kwa sababu hakuna kikundi cha udhibiti (control group) cha kulinganisha nacho.

Tunahitaji njia ya kupima miundo yetu. Lazima tutenganishe utata wa msingi (essential complexity) na utata wa bahati mbaya (accidental complexity). Utata wa msingi ni tatizo lenyewe. Utata wa bahati mbaya ni vurugu tunazozitengeneza kwa zana na michakato yetu.

AI inafanya utekelezaji kuwa wa karibu bure. Hii ni mabadiliko makubwa. Hapo awali, ugumu wa kuandika kodi uliwalazimu watengenezaji (developers) kutengeneza miundo bora zaidi. Ikiwa kodi yako ilikuwa na vurugu, ilikuwa vigumu kuisimamia. Maumivu hayo yalikuwa mzunguko wa mrejesho (feedback loop).

AI inaondoa ugumu huo. Inaweza kuandika kodi yenye vurugu na miundo mibaya kwa kasi ileile kama kodi safi. Maumivu ya mfumo mbaya hayatampata mtengenezaji wakati wa ujenzi (build). Badala yake, maumivu hayo yanahamia kwenye uzalishaji (production). Unapata data iliyoharibika na kazi za muunganisho (integration) zisizowezekana.

Mfumo tajiri wa kikoa (rich domain model) ni chombo cha kuzuia hili. Unatekeleza kazi tatu mahususi:

  • Inakusaidia kujifunza kikoa kwa kukulazimisha kuupa dhana umbo.
  • Inafafanua kikoa ili "nini cha kujenga" kusiwe makisio tena.
  • Inauandika kikoa katika kodi ambayo inabaki kuwa mpya kupitia kirekebisha kodi (compiler).

Ili kufanya kazi, mfumo wa kikoa lazima ufuate sheria tatu:

  • Weka utata wa msingi ukiwa pamoja. Usitawanye dhana moja katika mamia ya microservices.
  • Toa mrejesho. Dhana isiyo sahihi inapaswa kusababisha hitilafu ya kirekebisha kodi (compile error), siyo hitilafu ya siri (silent bug).
  • Fanya mabadiliko yawe na gharama nafuu. Unapaswa kurekebisha dhana mahali pamoja, siyo kuitafuta katika huduma (services) kumi.

Ikiwa utagawanya kikoa chako mapema sana katika microservices ili kutatua "uvimbe" (bloat), mara nyingi unahamisha tu vurugu hizo. Unabadilisha "god object" moja kwa vurugu zilizosambazwa ambazo ni ngumu zaidi kufuatilia. Utegemezi (dependency) ambao huwezi kuuona ni utegemezi utakaovunjika wakati wa uzalishaji (production).

Lengo la mfumo tajiri wa kikoa si kuwa sahihi. Lengo ni kufanya makosa yaonekane wakati gharama ya marekebisho bado ni ndogo.

Chanzo: https://dev.to/leonpennings/what-is-the-reason-for-using-a-rich-domain-model-in-the-age-of-ai-3gg

Jumuia ya hiari ya kujifunza: https://t.me/GyaanSetuAi