𝗗𝗗𝗗 മരിക്കുകയല്ല. 𝗖𝗮𝗿𝗴𝗼-𝗖𝘂ള്𝘁 𝗗𝗗𝗗 ആണ് മരിക്കുന്നത്.
Domain-Driven Design (DDD) മരിക്കുകയല്ല.
AI വന്നതോടെ DDD-യുടെ അടിസ്ഥാന മൂല്യങ്ങൾക്ക് ഇപ്പോൾ കൂടുതൽ പ്രാധാന്യമുണ്ട്. നിങ്ങൾക്ക് ഇപ്പോഴും ഇവ ആവശ്യമാണ്:
- സങ്കീർണ്ണമായ ബിസിനസ്സ് ഡൊമെയ്നുകൾ (business domains) മനസ്സിലാക്കുക
- bounded contexts നിർവചിക്കുക
- എഞ്ചിനീയർമാരും വിദഗ്ധരും തമ്മിലുള്ള ഭാഷാപരമായ ഐക്യം ഉറപ്പാക്കുക
- invariants കണ്ടെത്തുക
- state transitions വ്യക്തമാക്കുക
കോഡ് നിർമ്മിക്കുന്നത് AI എളുപ്പമാക്കുന്നു. ഇത് അസ്പഷ്ടമായ ചിന്താഗതികളെ കൂടുതൽ അപകടകരമാക്കുന്നു. നിങ്ങളുടെ ഡൊമെയ്ൻ ലോജിക് (domain logic) കുഴപ്പത്തിലാണെങ്കിൽ, കൂടുതൽ വേഗത്തിൽ ആ കുഴപ്പങ്ങൾ സൃഷ്ടിക്കാൻ AI നിങ്ങളെ സഹായിക്കുകയേയുള്ളൂ.
പ്രശ്നം DDD അല്ല. പ്രശ്നം കാർഗോ-കൾട്ട് (cargo-cult) DDD ആണ്.
പല ടീമുകളും തന്ത്രപരമായ (tactical) DDD-യെ മനസ്സിലാക്കുന്നതിനേക്കാൾ ഉപരിയായി നിയന്ത്രണത്തിനുള്ള ഒരു ഉപാധിയായാണ് ഉപയോഗിക്കുന്നത്. അവർ പാറ്റേണുകൾ പിന്തുടരുന്നത് വെറുതെ പിന്തുടരാൻ വേണ്ടി മാത്രമാണ്:
- ഒരു Entity നിർമ്മിക്കുക
- ഒരു Repository ചേർക്കുക
- ഒരു Mapper എഴുതുക
- ഡയറക്ടറി സ്ട്രക്ചർ പിന്തുടരുക
ഈ പാറ്റേണുകൾ മോശമല്ല. എന്നാൽ അവ പലപ്പോഴും ആർക്കിടെക്ചറൽ പേപ്പർവർക്ക് (architectural paperwork) ആയി മാറുന്നു. ഒരു Repository എന്നത് വെറുമൊരു പുനർനാമകരണം ചെയ്ത DAO മാത്രമാണെങ്കിലോ, അല്ലെങ്കിൽ ഒരു Mapper അർത്ഥശൂന്യമായി ഫീൽഡുകൾ മാറ്റുക മാത്രമാണെങ്കിലോ, നിങ്ങൾ ഒരു ഡൊമെയ്നിനെ മോഡൽ ചെയ്യുകയല്ല ചെയ്യുന്നത്. നിങ്ങൾ വെറുതെ ഫോമുകൾ പൂരിപ്പിക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
ഇത് ആർക്കിടെക്ചർ രൂപത്തിൽ പ്രകടമാകുന്ന ഉദ്യോഗസ്ഥ മേധാവിത്വമാണ് (bureaucracy).
ഇത്തരം ജോലികൾ ചെയ്യാൻ AI തികച്ചും അനുയോജ്യമാണ്. സെക്കൻഡുകൾക്കുള്ളിൽ mappers, DTOs, boilerplate എന്നിവ നിർമ്മിക്കാൻ ഇതിന് കഴിയും.
ഉദ്യോഗസ്ഥ മേധാവിത്വം (bureaucracy) വേഗത്തിലാക്കാൻ നിങ്ങൾ AI ഉപയോഗിക്കുകയാണെങ്കിൽ, നിങ്ങൾ വെറും ചടങ്ങുകൾ (ceremony) മാത്രമാണ് വേഗത്തിലാക്കുന്നത്. കൂടുതൽ ടിക്കറ്റുകൾ നീങ്ങുന്നത് നിങ്ങൾ കാണുന്നുണ്ടാകാം, പക്ഷേ നിങ്ങൾ മികച്ച സിസ്റ്റങ്ങൾ നിർമ്മിക്കുകയല്ല ചെയ്യുന്നത്. നിങ്ങൾ വെറുതെ പാഴായ കാര്യങ്ങൾ കുറഞ്ഞ ചിലവിൽ നിർമ്മിക്കുക മാത്രമാണ് ചെയ്യുന്നത്.
യഥാർത്ഥ മത്സരം രണ്ട് തരം സംഘടനകൾ തമ്മിലാണ്:
വലിയ AI-അധിഷ്ഠിത ഉദ്യോഗസ്ഥ മേധാവിത്വമുള്ള ടീമുകൾ (Large AI-assisted bureaucratic teams) ഈ ടീമുകൾ കൂടുതൽ ലെയറുകളും കൂടുതൽ boilerplate-ഉം നിർമ്മിക്കാൻ AI ഉപയോഗിക്കുന്നു. നിലവിലുള്ള പാറ്റേണുകൾ പിന്തുടരുന്നതിനും ഫോർമൽ റിവ്യൂകൾ പാസാക്കുന്നതിനുമാണ് അവർ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത്.
ചെറിയ AI-അധിഷ്ഠിത ഉയർന്ന ഉത്തരവാദിത്തമുള്ള ടീമുകൾ (Small AI-amplified high-ownership teams) സിസ്റ്റങ്ങളിൽ സുരക്ഷിതമായി മാറ്റങ്ങൾ വരുത്താനുള്ള കഴിവ് വർദ്ധിപ്പിക്കാൻ ഈ ടീമുകൾ AI ഉപയോഗിക്കുന്നു. അവർ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നത് ഇവയിലാണ്:
- എക്സിക്യൂട്ടബിൾ സ്പെസിഫിക്കേഷനുകൾ (Executable specifications)
- ശക്തമായ അതിരുകൾ (Strong boundaries)
- ഓട്ടോമേറ്റഡ് ടെസ്റ്റുകൾ (Automated tests)
- ടൈപ്പ്-ലെവൽ നിയന്ത്രണങ്ങൾ (Type-level constraints)
- വ്യക്തമായ സ്റ്റേറ്റ് ട്രാൻസിഷനുകൾ (Explicit state transitions)
ആദ്യത്തെ തരം AI ഉപയോഗിക്കുന്നത് കൂടുതൽ ചടങ്ങുകൾ (ceremony) ഉണ്ടാക്കാനാണ്. രണ്ടാമത്തെ തരം AI ഉപയോഗിക്കുന്നത് ചടങ്ങുകളുടെ ആവശ്യം ഇല്ലാതാക്കാനാണ്.
ആളുകളെയോ കോഡിനെയോ നിയന്ത്രിക്കാൻ ആർക്കിടെക്ചർ ഉപയോഗിക്കുന്നത് നിർത്തുക. ഡൊമെയ്ൻ അർത്ഥത്തെ (domain meaning) സംരക്ഷിക്കാൻ അത് ഉപയോഗിക്കുക.
മനുഷ്യരുടെ റിവ്യൂവിലൂടെ സംരക്ഷിക്കപ്പെടുന്ന ആർക്കിടെക്ചറിൽ നിന്ന് ടെസ്റ്റുകൾ, ടൈപ്പുകൾ, നിയന്ത്രണങ്ങൾ (constraints) എന്നിവയിലൂടെ സംരക്ഷിക്കപ്പെടുന്ന ആർക്കിടെക്ചറിലേക്ക് മാറൂ.
Source: https://dev.to/terum/ddd-is-not-dying-cargo-cult-ddd-is-l1p
Optional learning community: https://t.me/GyaanSetuAi