మంచి సేవా సరిహద్దులు వ్యాపార సామర్థ్యాలను అనుసరిస్తాయి, సాంకేతిక పొరలను కాదు. Domain-Driven Design (DDD) దీనికి ఒక ఖచ్చితమైన సాధనాన్ని ఇస్తుంది: bounded context — ఒక సరిహద్ద, దీనిలో డొమైన్ మోడల్ మరియు దాని నిబంధనలు స్థిరంగా ఉన్నాయి.
"కస్టమర్" అనే పదం వివిధ సందర్భాలలో వేర్వేరు విషయాలను అర్థం చేయవచ్చు. ప్రతి 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 మీకు వ్యాపారం వెంట ఈ లైన్లను గీయడానికి సూత్రప్రాయమైన మార్గాన్ని ఇస్తుంది, తద్వారా సేవలు సంపూర్ణంగా ఉన్నాయి మరియు నిరంతరం సమన్వయం చేయకుండా స్వతంత్రంగా అభివృద్ధి చెందుతాయి.