ਚੰਗੀਆਂ ਸੇਵਾ ਦੀਆਂ ਸੀਮਾਵਾਂ ਕਾਰੋਬਾਰੀ ਸਮਰੱਥਾਵਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੀਆਂ ਹਨ, ਨਾ ਕਿ ਤਕਨੀਕੀ ਪਰਤਾਂ। Domain-Driven Design (DDD) ਇਸ ਲਈ ਇੱਕ ਸਟੀਕ ਸਾਧਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: bounded context — ਇੱਕ ਸੀਮਾ ਜਿਸ ਦੇ ਅੰਦਰ ਇੱਕ ਡੋਮੇਨ ਮਾਡਲ ਅਤੇ ਇਸ ਦੀਆਂ ਸ਼ਰਤਾਂ ਇਕਸਾਰ ਹੋਣ।
"Customer" ਸ਼ਬਦ ਵੱਖ-ਵੱਖ ਸੁਮੇਲਾਂ ਵਿੱਚ ਵੱਖ-ਵੱਖ ਅਰਥ ਰੱਖ ਸਕਦਾ ਹੈ। ਹਰੇਕ bounded context ਆਪਣਾ ਮਾਡਲ ਸੰਭਾਲਦਾ ਹੈ, ਅਤੇ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸੁਮੇਲੇ ਨੂੰ ਮੈਪ ਕਰਦਾ ਹੈ।
┌───────────────────┐ ┌────────────────────┐
│ Sales context │ │ Support context │
│ Customer = │ │ Customer = │
│ leads, orders │ │ tickets, SLAs │
└───────────────────┘ └────────────────────┘
one service another service
✗ Entity services ("User service", "Product service") — too fine, chatty
✗ Splitting by technical layer (a "database service")
✗ Boundaries that force a distributed transaction for every operation
ਜੇ ਦੋ ਸੇਵਾਵਾਂ ਇੱਕ ਕਾਰਜ ਪੂਰਾ ਕਰਨ ਲਈ ਲਗਾਤਾਰ ਇੱਕ ਦੂਜੇ ਨੂੰ ਕਾਲ ਕਰਦੀਆਂ ਹਨ, ਤਾਂ ਸੀਮਾ ਸ਼ਾਇਦ ਗਲਤ ਹੈ।
ਜਲਦੀ ਨਿਰਧਾਰਤ ਕੀਤੀਆਂ ਗਈਆਂ ਸੀਮਾਵਾਂ ਬਾਅਦ ਵਿੱਚ ਹਟਾਉਣਾ ਬਹੁਤ ਮਹਿੰਗਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ API ਅਤੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਸਖ਼ਤ ਹੋ ਜਾਂਦੀਆਂ ਹਨ ਜਿਸ 'ਤੇ ਦੂਸਰੀਆਂ ਟੀਮਾਂ ਨਿਰਭਰ ਕਰਦੀਆਂ ਹਨ।
DDD bounded contexts ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਲਾਈਨਾਂ ਨੂੰ ਕਾਰੋਬਾਰ ਦੇ ਨਾਲ ਖਿੱਚਣ ਦਾ ਇੱਕ ਸੰਤੁਲਿਤ ਤਰੀਕਾ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਜੋ ਸੇਵਾਵਾਂ ਇਕਜੁੱਟ ਰਹਿਣ ਅਤੇ ਲਗਾਤਾਰ ਤਾਲਮੇਲ ਕਰਨ ਦੀ ਬਜਾਏ ਸੁਤੰਤਰ ਰੂਪ ਵਿੱਚ ਵਿਕਸਤ ਹੋ ਸਕਣ।
ਵਿਸਤ੍ਰਿਤ ਜਵਾਬਾਂ ਨਾਲ IT ਇੰਟਰਵਿਊ ਸਵਾਲਾਂ ਦੀ ਇੱਕ ਲਾਇਬ੍ਰੇਰੀ — ਜੂਨੀਅਰ ਤੋਂ ਸੀਨੀਅਰ ਤੱਕ।
ਦਾਨ ਕਰੋ