𝗪𝗵𝘆 𝗗𝗼𝗺𝗮𝗶𝗻 𝗠𝗼𝗱𝗲𝗹𝘀 𝗠𝗮𝘁𝘁𝗲𝗿 𝗠𝗼𝗿𝗲 𝗶𝗻 𝘁𝗵𝗲 𝗔𝗜 𝗘𝗿𝗮

ਸਾਫਟਵੇਅਰ ਆਰਕੀਟੈਕਚਰ (Software architecture) ਅਕਸਰ ਇੱਕ ਅਜਿਹੀ ਬਹਿਸ ਹੁੰਦੀ ਹੈ ਜਿਸਦਾ ਕੋਈ ਜੇਤੂ ਨਹੀਂ ਹੁੰਦਾ। ਤੁਸੀਂ ਇੱਕ ਸਿਸਟਮ ਬਣਾਉਂਦੇ ਹੋ। ਤੁਸੀਂ ਕਦੇ ਵੀ ਉਸੇ ਸਥਿਤੀ ਵਿੱਚ ਕੋਈ ਵਿਕਲਪ ਨਹੀਂ ਬਣਾਉਂਦੇ। ਇਹ ਹਰ ਫੈਸਲੇ ਨੂੰ ਅਜਿਹਾ ਬਣਾ ਦਿੰਦਾ ਹੈ ਜਿਸ ਨੂੰ ਗਲਤ ਸਾਬਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਜਦੋਂ ਕੋਈ ਸਿਸਟਮ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਲੋਕ ਡੋਮੇਨ ਜਾਂ ਟੀਮ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਦੇ ਹਨ। ਉਹ ਸ਼ਾਇਦ ਹੀ ਕਦੇ ਆਰਕੀਟੈਕਚਰ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਦੇ ਹਨ ਕਿਉਂਕਿ ਇਸਦੀ ਤੁਲਨਾ ਕਰਨ ਲਈ ਕੋਈ ਕੰਟਰੋਲ ਗਰੁੱਪ ਨਹੀਂ ਹੁੰਦਾ।

ਸਾਨੂੰ ਆਪਣੇ ਡਿਜ਼ਾਈਨਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਤਰੀਕੇ ਦੀ ਲੋੜ ਹੈ। ਸਾਨੂੰ 'essential complexity' ਨੂੰ 'accidental complexity' ਤੋਂ ਵੱਖ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। Essential complexity ਅਸਲ ਸਮੱਸਿਆ ਹੈ। Accidental complexity ਉਹ ਗੜਬੜ ਹੈ ਜੋ ਅਸੀਂ ਆਪਣੇ ਟੂਲਸ ਅਤੇ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਾਲ ਪੈਦਾ ਕਰਦੇ ਹਾਂ।

AI ਇੰਪਲੀਮੈਂਟੇਸ਼ਨ (implementation) ਨੂੰ ਲਗਭਗ ਮੁਫ਼ਤ ਬਣਾ ਦਿੰਦਾ ਹੈ। ਇਹ ਇੱਕ ਬਹੁਤ ਵੱਡਾ ਬਦਲਾਅ ਹੈ। ਪਹਿਲਾਂ, ਕੋਡ ਲਿਖਣ ਦੀ ਮੁਸ਼ਕਲ ਨੇ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਬਿਹਤਰ ਢਾਂਚੇ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਸੀ। ਜੇਕਰ ਤੁਹਾਡਾ ਕੋਡ ਗੜਬੜ ਵਾਲਾ ਸੀ, ਤਾਂ ਇਸਨੂੰ ਸੰਭਾਲਣਾ ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦਾ ਸੀ। ਉਹ ਦਰਦ ਇੱਕ ਫੀਡਬੈਕ ਲੂਪ (feedback loop) ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਸੀ।

AI ਉਸ ਰੁਕਾਵਟ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਸਾਫ਼ ਕੋਡ ਦੀ ਤਰ੍ਹਾਂ ਹੀ ਗੜਬੜ ਵਾਲਾ ਅਤੇ ਮਾੜੇ ਢਾਂਚੇ ਵਾਲਾ ਕੋਡ ਬਹੁਤ ਤੇਜ਼ੀ ਨਾਲ ਲਿਖ ਸਕਦਾ ਹੈ। ਇੱਕ ਮਾੜੇ ਮਾਡਲ ਦਾ ਦਰਦ ਹੁਣ ਬਿਲਡ (build) ਦੌਰਾਨ ਡਿਵੈਲਪਰ ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਕਰਦਾ। ਇਸ ਦੀ ਬਜਾਏ, ਉਹ ਦਰਦ ਪ੍ਰੋਡਕਸ਼ਨ (production) ਵਿੱਚ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਖਰਾਬ ਡੇਟਾ ਅਤੇ ਅਸੰਭਵ ਇੰਟੀਗ੍ਰੇਸ਼ਨ (integration) ਕੰਮਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈਂਦਾ ਹੈ।

ਇੱਕ ਰਿਚ ਡੋਮੇਨ ਮਾਡਲ (rich domain model) ਇਸ ਤੋਂ ਬਚਣ ਲਈ ਇੱਕ ਸਾਧਨ ਹੈ। ਇਹ ਤਿੰਨ ਖਾਸ ਕੰਮ ਕਰਦਾ ਹੈ:

  • ਇਹ ਤੁਹਾਨੂੰ ਸੰਕਲਪਾਂ (concepts) ਨੂੰ ਇੱਕ ਰੂਪ ਦੇਣ ਲਈ ਮਜਬੂਰ ਕਰਕੇ ਡੋਮੇਨ ਨੂੰ ਸਿੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ।
  • ਇਹ ਡੋਮੇਨ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ "ਕੀ ਬਣਾਉਣਾ ਹੈ" ਇਹ ਕੋਈ ਅੰਦਾਜ਼ਾ ਨਾ ਰਹੇ।
  • ਇਹ ਕੋਡ ਵਿੱਚ ਡੋਮੇਨ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਜੋ ਕੰਪਾਈਲਰ (compiler) ਰਾਹੀਂ ਅਪਡੇਟ ਰਹਿੰਦਾ ਹੈ।

ਕੰਮ ਕਰਨ ਲਈ, ਇੱਕ ਡੋਮੇਨ ਮਾਡਲ ਨੂੰ ਤਿੰਨ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

  • Essential complexity ਨੂੰ ਸੰਪੂਰਨ ਰੱਖੋ। ਇੱਕ ਸਿੰਗਲ ਸੰਕਲਪ ਨੂੰ ਸੈਂਕੜੇ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ (microservices) ਵਿੱਚ ਨਾ ਖਿਲਾਰੋ।
  • ਫੀਡਬੈਕ ਪ੍ਰਦਾਨ ਕਰੋ। ਇੱਕ ਗਲਤ ਅੰਦਾਜ਼ੇ ਕਾਰਨ ਕੰਪਾਈਲ ਐਰਰ (compile error) ਆਉਣਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਕੋਈ ਚੁੱਪਚਾਪ ਰਹਿਣ ਵਾਲਾ ਬੱਗ (silent bug)।
  • ਬਦਲਾਅ ਸਸਤੇ ਰੱਖੋ। ਤੁਹਾਨੂੰ ਇੱਕ ਸੰਕਲਪ ਨੂੰ ਇੱਕੋ ਜਗ੍ਹਾ 'ਤੇ ਠੀਕ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ, ਨਾ ਕਿ ਦਸ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਉਸਨੂੰ ਲੱਭਣਾ ਪਵੇ।

ਜੇਕਰ ਤੁਸੀਂ "bloat" ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਆਪਣੇ ਡੋਮੇਨ ਨੂੰ ਬਹੁਤ ਜਲਦੀ ਮਾਈਕਰੋਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਵੰਡ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਅਕਸਰ ਸਿਰਫ਼ ਗੜਬੜ ਨੂੰ ਇੱਕ ਥਾਂ ਤੋਂ ਦੂਜੀ ਥਾਂ ਲੈ ਜਾਂਦੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਸਿੰਗਲ "god object" ਦੇ ਬਦਲੇ ਇੱਕ ਵੰਡਿਆ ਹੋਇਆ (distributed) ਗੜਬੜ ਵਾਲਾ ਢਾਂਚਾ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹੋ ਜਿਸ ਨੂੰ ਟਰੈਕ ਕਰਨਾ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਹੁੰਦਾ ਹੈ। ਇੱਕ ਡਿਪੈਂਡੈਂਸੀ (dependency) ਜਿਸਨੂੰ ਤੁਸੀਂ ਦੇਖ ਨਹੀਂ ਸਕਦੇ, ਉਹ ਅਜਿਹੀ ਡਿਪੈਂਡੈਂਸੀ ਹੈ ਜੋ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਟੁੱਟ ਜਾਵੇਗੀ।

ਇੱਕ ਰਿਚ ਡੋਮੇਨ ਮਾਡਲ ਦਾ ਉਦੇਸ਼ ਸਹੀ ਹੋਣਾ ਨਹੀਂ ਹੈ। ਉਦੇਸ਼ ਗਲਤ ਹੋਣ ਨੂੰ ਉਦੋਂ ਦਿਖਾਈ ਦੇਣ ਯੋਗ ਬਣਾਉਣਾ ਹੈ ਜਦੋਂ ਸੁਧਾਰ ਕਰਨ ਦੀ ਲਾਗਤ ਅਜੇ ਵੀ ਘੱਟ ਹੋਵੇ।

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

ਵਿਕਲਪਿਕ ਲਰਨਿੰਗ ਕਮਿਊਨਿਟੀ: https://t.me/GyaanSetuAi