वास्तविक जीवन के लिए व्यावहारिक Angular आर्किटेक्चर

अधिकांश कोणीय वास्तुकला पाठ्यक्रम सिद्धांत पढ़ाते हैं। ये वाला नहीं.

यहां आप वास्तविक समस्याओं का पता लगाना, स्थित निर्णय लेना और ऐसी प्रणालियां बनाना सीखते हैं जो टीम के बढ़ने, उत्पाद बदलने और समय बीतने पर भी कायम रहती हैं।

बीस मॉड्यूल. अभ्यास उन्मुख. कोई पैडिंग नहीं.

---

सूचकांक - वास्तविक जीवन के लिए व्यावहारिक कोणीय वास्तुकला

---

मॉड्यूल 0 - सिस्टम बेस

बिंदु 0 एक सामग्री मॉड्यूल नहीं है. यह देखने का वह तरीका है जिसका उपयोग आप पूरे रोडमैप में करेंगे।

एंगुलर में विशिष्ट समस्याओं के बारे में बात करने से पहले, आपको एक प्रश्न का उत्तर देना होगा:

आप किसी ऐसे ऐप को कैसे देखते हैं जिसे आप नहीं जानते हैं और तय करते हैं कि यह अच्छा है या बुरा?

उसके लिए चार बुनियादी कौशल हैं।

---

1. कोड को छुए बिना किसी ऐप का विश्लेषण करें

किसी ऐप की पहली रीडिंग संपादक में नहीं होती है। यह संरचना में है. किसी एकल फ़ाइल को खोलने से पहले, आप जानकारी निकाल सकते हैं:

• फोल्डर किसे कहते हैं? क्या नाम बताते हैं कि वे क्या करते हैं?
• क्या कोई फ़ोल्डर shared है जिसका वजन अन्य सभी चीज़ों से अधिक है? -संरचना में घोंसले बनाने के कितने स्तर हैं?
• क्या मॉड्यूल या सुविधाओं में डोमेन नाम या तकनीकी नाम हैं?
• सेवाएँ कहाँ हैं? ढीला या सुविधाओं के भीतर?

यह आपको पहले से ही इस बारे में बहुत कुछ बताता है कि जिसने भी ऐप बनाया है उसने व्यावसायिक दृष्टि से सोचा है या तकनीकी परतों के रूप में।

---

2. वास्तुकला की व्यावहारिक तरीके से समीक्षा करें

समीक्षा करना कोड को ऊपर से नीचे तक पढ़ना नहीं है। यह मानदंड के साथ प्रश्न पूछ रहा है:

• व्यावसायिक तर्क कहाँ रहता है?
• कौन जानता है कि प्रत्येक परत में क्या है?
• नई सुविधा जोड़ने के लिए आपको कितनी साइटें बदलनी होंगी?
• क्या निर्भरताएं गलत दिशा में जा रही हैं?

एक वरिष्ठ वास्तुकार सबसे जटिल घटक से शुरुआत नहीं करता है। उच्चतम जोखिम बिंदुओं से प्रारंभ करें: साझा सेवाएँ, वैश्विक स्थिति और डेटा एक्सेस परत।

---

3. प्रोग्रामिंग से पहले समस्याओं का पता लगाएं

अधिकांश वास्तुशिल्प क्षति शुरुआती निर्णयों में होती है जो अप्रासंगिक लगते हैं:

• "मैं इसे अभी एक साझा सेवा पर डाल रहा हूं"
• "मूल घटक इस स्थिति को संभालता है, फिर हम इसे आगे बढ़ाते हैं"
• "हम हर चीज़ के लिए NgRx का उपयोग करते हैं, इसलिए यह सुसंगत है"

इन निर्णयों के वास्तविक परिणाम महीनों बाद सामने आते हैं। वास्तुशिल्प मानदंड यह जानना है कि प्रत्येक निर्णय क्या खरीद रहा है और उस पर कितना कर्ज हो रहा है।

---

4. सिद्धांत को वास्तविक चेकलिस्ट में बदलें

प्रत्येक अवधारणा जो हम इस रोडमैप में देखेंगे - स्मार्ट/डंब घटक, राज्य प्लेसमेंट, ईश्वर सेवाएँ, आदि - को एक प्रश्न के साथ समाप्त करना होगा जिसे आप वास्तविक कोड की समीक्षा करते समय स्वयं से पूछ सकते हैं:

• क्या यह घटक जानता है कि डेटा कहाँ से आता है?
• क्या इस सेवा में बदलाव के एक से अधिक कारण हैं?
• क्या यह राज्य दो अलग-अलग जगहों पर मौजूद है?

यदि आप किसी अवधारणा को समीक्षा प्रश्न में नहीं बदल सकते हैं, तो आपने इसे अभी तक आत्मसात नहीं किया है।

---

मॉड्यूल 1 - कोड को छुए बिना एंगुलर ऐप का विश्लेषण कैसे करें

पहली वास्तुशिल्प समीक्षा संपादक खोलने से पहले होती है। केवल फ़ोल्डर संरचना और फ़ाइल नामों से आप पहले से ही गुणवत्ता के स्पष्ट संकेत प्राप्त कर सकते हैं। एक वरिष्ठ वास्तुकार किसी अज्ञात ऐप के साथ पहले 10 मिनट में यही करेगा।

क्या फर्क पड़ता है?

• यदि आपको वास्तु संबंधी समस्याओं का पता लगाने में लंबा समय लगता है, तो उन्हें ठीक करने की लागत तेजी से बढ़ जाती है।
• पहले दिन से ही खराब डिज़ाइन की गई संरचना तकनीकी ऋण बन जाती है जो महीनों बाद टीम को अवरुद्ध कर देती है।
• त्वरित दृश्य निर्णय विकसित करने से आप कोड की एक पंक्ति लिखने से पहले बेहतर निर्णय ले सकते हैं।

चरण 1 - फ़ोल्डर संरचना को मानचित्र के रूप में पढ़ें

फ़ोल्डर संरचना पहला दृश्यमान वास्तुशिल्प निर्णय है। यह आपको बताता है कि टीम ने अपनी मानसिक दुनिया को कैसे व्यवस्थित किया: क्या वे प्रौद्योगिकी के संदर्भ में सोचते हैं या व्यवसाय के संदर्भ में?

विशेषता क्या है?

एक सुविधा एक संपूर्ण व्यावसायिक कार्यक्षमता है. फ़ाइल प्रकार नहीं. कोई तकनीकी परत नहीं.

एक ईकॉमर्स ऐप के बारे में सोचें। विशेषताएं हैं:

• उत्पाद सूची
• शॉपिंग कार्ट
• चेकआउट प्रक्रिया
• उपयोगकर्ता प्रोफ़ाइल
• प्रबंधन को आदेश दें

उनमें से प्रत्येक व्यवसाय का एक हिस्सा है जो अपने आप में मायने रखता है। एक उपयोगकर्ता प्रवेश करता है, कैटलॉग ब्राउज़ करता है, कार्ट में जोड़ता है, चेक आउट करता है। वे विशेषताएं हैं.

मॉडल 1 - तकनीकी परतों द्वारा संगठन (पैमाने पर समस्याग्रस्त)

लगभग हर कोई शुरुआत करते समय यही करता है क्योंकि यह साफ-सुथरा लगता है:

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

वास्तविक समस्या: आपको चेकआउट प्रवाह को संशोधित करना होगा। यह समझने के लिए कि इसमें क्या शामिल है, आप तीन अलग-अलग फ़ोल्डरों के बीच नेविगेट करते हैं - आप components/ में घटक, services/ में सेवा, models/ में मॉडल ढूंढते हैं। यदि कोई विशिष्ट चेकआउट पाइप है, तो वह pipes/ में अन्य सुविधाओं के पाइपों के साथ मिश्रित है।

किसी एक सुविधा को बदलने के लिए, आप संपूर्ण ऐप में नेविगेट करते हैं। वह संरचना द्वारा युग्मन है। जब टीम बढ़ती है, तो अलग-अलग सुविधाओं पर काम करने वाले दो लोग लगातार एक ही फ़ोल्डर को छूते हैं → गिट में टकराव, यह जानने में कठिनाई होती है कि किसके पास क्या है।

मॉडल 2 - सुविधाओं के आधार पर संगठन (क्या पैमाने)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

यह क्यों काम करता है: जब आप चेकआउट पर टैप करते हैं, तो चेकआउट में सब कुछ एक साथ होता है। एक नया डेवलपर ठीक-ठीक जानता है कि उसे कहां देखना है। एक व्यक्ति संपूर्ण सुविधा का स्वामी हो सकता है. आप केवल उसके फ़ोल्डर को हटाकर संपूर्ण सुविधा को हटा सकते हैं। विभिन्न विशेषताओं के बीच Git संघर्ष लगभग पूरी तरह से गायब हो जाता है।

मुख्य नियम: यदि आप कोई सुविधा हटाते हैं, तो क्या आप किसी अन्य चीज़ को छुए बिना उसका पूरा फ़ोल्डर हटा सकते हैं? यदि उत्तर हाँ है, तो सुविधा अच्छी तरह से पृथक है। यदि आपको पूरे ऐप में टुकड़ों की तलाश करनी है, तो ऐसा नहीं है।

चरण 2 - नाम पढ़ें

नाम दस्तावेज हैं. एक बुरा नाम इरादे को छुपाता है और कोड पढ़ने वाले प्रत्येक व्यक्ति पर संज्ञानात्मक भार जोड़ता है।

shared/ - इसमें क्या होना चाहिए और क्या नहीं

shared/ उन चीज़ों के लिए है जो एकाधिक सुविधाओं का उपयोग करती हैं और जिनका अपना व्यावसायिक तर्क नहीं होता है।

shared/ में सही:

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

वे पुन: प्रयोज्य यूआई टुकड़े या शुद्ध उपयोगिताएँ हैं। उन्हें बिजनेस के बारे में कुछ भी पता नहीं है. ButtonComponent को यह नहीं पता कि यह चेकआउट या उपयोगकर्ता प्रोफ़ाइल बटन है। वह केवल बटन बनना जानता है।

shared/ में ग़लत:

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

जब आप shared/ के अंदर व्यावसायिक तर्क वाली सेवाएँ देखते हैं, तो इसका मतलब है कि किसी को नहीं पता कि उन्हें कहाँ रखा जाए और उन्हें वहाँ रखा जाए। समय के साथ shared/ ऐप का आकर्षण बन जाता है।

core/ - यह क्या है और क्या नहीं

core/ सिंगलटन इंफ्रास्ट्रक्चर के लिए है जिसके लिए एक बार पूरे ऐप की आवश्यकता होती है।

core/ में सही:

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

core/ में ग़लत:

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

ये ऐसी चीज़ें हैं जो एक बार चालू होती हैं और पूरे ऐप को प्रभावित करती हैं। प्रमाणीकरण इंटरसेप्टर संपूर्ण ऐप के लिए सभी HTTP अनुरोधों को रोकता है, यही कारण है कि यह core/ में रहता है।

अस्पष्ट नाम - लाल झंडे

अस्पष्ट नाम एक स्थगित निर्णय है. जब कोई data.service.ts बनाता है, तो उन्होंने यह तय नहीं किया है कि वह सेवा किस डेटा के बारे में बात कर रही है।

आपने क्या देखा	इसका क्या मतलब हो सकता है
shared/ बहुत बड़ा	वह सब कुछ जो कहीं और फिट नहीं बैठता। यह एक मिश्रित बैग बन जाता है.
common/	shared/ के समान, लेकिन नाम ख़राब है। क्या अंदर जाता है इसके मानदंड के बिना।
सेवाओं के साथ utils/	व्यावसायिक तर्क उपयोगिता के भेष में छिपा हुआ है। गंभीर लाल झंडा.
helpers/	utils/ के समान। नाम जिम्मेदारी के बारे में कुछ नहीं कहता.
जड़ में components/	डोमेन के अनुसार कोई संगठन नहीं. सभी घटक एक साथ.
core/ 40 फ़ाइलों के साथ	ख़राब ढंग से परिभाषित कोर. shared/ का उपयोग दूसरे के रूप में किया गया था।
app.service.ts	एक ईश्वरीय सेवा बढ़ने की प्रतीक्षा कर रही है। अधिकतम अलार्म संकेत.
data.service.ts	किस पर डेटा? नाम से अनिश्चितकालीन जिम्मेदारी.
helper.service.ts	यह असंबंधित तरीकों वाली एक सेवा बनकर रह जाती है।
main.component.ts	"मुख्य" क्या है? सामान्य नाम जो वास्तविक जिम्मेदारी छुपाता है।

नाम नियम: यदि फ़ाइल का नाम आपको बिल्कुल नहीं बताता कि वह क्या करता है, तो फ़ाइल संभवतः बहुत अधिक कार्य करती है या ख़राब स्थिति में है।

अस्पष्ट नामों के ठोस उदाहरण और वे क्या छिपाते हैं:

• utils/format.ts 800 पंक्तियों के साथ: दिनांक स्वरूपण + प्रपत्र सत्यापन + एपीआई परिवर्तन का मिश्रण।
• helper.service.ts: अंतत: असंबंधित तरीकों से ईश्वरीय सेवा बन जाती है।
• app.service.ts: एक सेवा जिसे संपूर्ण ऐप कहा जाता है, जिसमें संपूर्ण ऐप की जिम्मेदारियां होती हैं।

चरण 3 - फ़ाइलें खोले बिना गिनें और मापें

कोड पढ़ने से पहले, आप सीधे संरचना से ये अवलोकन कर सकते हैं:

एक संकेत के रूप में घटक का आकार

संकेत	यह क्या दर्शाता है?
एक घटक में +300-400 पंक्तियाँ	आप लगभग हमेशा बहुत अधिक कार्य कर रहे होते हैं। यह कोई पूर्ण नियम नहीं है लेकिन यह जांच के लायक है।
+10 इनपुट और आउटपुट	बहुत जटिल एपीआई. उम्मीदवार को कई घटकों में बांटा जाएगा.
घटक में प्रत्यक्ष HTTP कॉल	प्रेजेंटेशन को डेटा एक्सेस के साथ मिलाएं। सेवा परत गायब है.
प्रति सुविधा 1-2 घटक	वे शायद बहुत ज़्यादा कर रहे हैं। आंतरिक विभाजन का अभाव.
+20 वैश्विक प्रदाता	बहुत अधिक राज्य और केंद्रीकृत तर्क। हर चीज़ का वैश्विक होना ज़रूरी नहीं है.

वैश्विक सेवाएँ - providedIn: 'root' का ख़तरा

एक वैश्विक सेवा का अर्थ है कि किसी भी सुविधा का कोई भी घटक उसे इंजेक्ट और उपयोग कर सकता है। यह उन विशेषताओं के बीच अदृश्य निर्भरताएँ बनाता है जो स्वतंत्र होनी चाहिए।

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

चरण 4 - app.module.ts या app.config.ts: क्या देखना है

मॉड्यूल वाले ऐप्स में (कोणीय <17 या लीगेसी)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

फ़ीचर मॉड्यूल को आलसी (मांग पर) लोड किया जाना चाहिए, सीधे रूट मॉड्यूल में आयात नहीं किया जाना चाहिए। यदि वे सभी यहां हैं, तो वे सभी स्टार्टअप पर लोड किए जाते हैं, भले ही उपयोगकर्ता को उनकी कभी आवश्यकता न हो।

स्टैंडअलोन ऐप्स में (Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

ग्लोबल कॉन्फिग नियम: ग्लोबल कॉन्फिगरेशन में केवल ऐसा इंफ्रास्ट्रक्चर होना चाहिए जो पूरे ऐप को प्रभावित करता हो: आलसी लोडिंग वाला राउटर, ग्लोबल इंटरसेप्टर, एनिमेशन, इंफ्रास्ट्रक्चर सिंगलटन सर्विसेज (ऑथ, लॉगर, एरर हैंडलर) के साथ HttpClient। यदि आप वैश्विक कॉन्फ़िगरेशन में फ़ीचर सेवाएँ देखते हैं, तो कोई व्यक्ति सुविधा के लिए विश्व स्तर पर चीज़ों को पंजीकृत कर रहा है, आवश्यकता के लिए नहीं।

संपूर्ण चेकलिस्ट - एंगुलर ऐप का पहला वाचन

संरचना

• क्या संरचना सुविधाओं (व्यावसायिक डोमेन) या तकनीकी परतों द्वारा व्यवस्थित है?
• क्या मैं किसी अन्य चीज़ को छुए बिना केवल उसके फ़ोल्डर को हटाकर संपूर्ण सुविधा को हटा सकता हूं?
• क्या सुविधाओं में व्यावसायिक डोमेन नाम (checkout, catalog) या तकनीकी नाम (list, form, detail) हैं?
• क्या अस्पष्ट नाम वाले फ़ोल्डर हैं: utils, helpers, common, misc, data?

shared/ और core/

• क्या shared/ में व्यावसायिक तर्क के बिना केवल यूआई घटक और उपयोगिताएँ शामिल हैं?
• क्या core/ में केवल सिंगलटन इंफ्रास्ट्रक्चर (इंटरसेप्टर, गार्ड, ऑथ सर्विस) शामिल है?
• क्या shared/ के भीतर व्यावसायिक तर्क वाली सेवाएँ हैं?
• क्या core/ में फीचर घटक या डोमेन सेवाएँ हैं?

सेवाएँ और प्रदाता

• क्या व्यावसायिक सेवाएँ आपकी सुविधाओं के भीतर हैं या विश्व स्तर पर ढीली हैं?
• क्या 20 से अधिक वैश्विक प्रदाता हैं?
• क्या रूट मॉड्यूल या app.config.ts फ़ीचर मॉड्यूल को सीधे आयात करता है (आलसी के बिना)?
• क्या providedIn: 'root' के साथ ऐसी सेवाएँ हैं जो किसी सुविधा के लिए स्थानीय होनी चाहिए?

नाम

• क्या फ़ाइल नाम वही कहते हैं जो वे करते हैं?
• क्या ऐसी फ़ाइलें हैं जिनका नाम ऐप के किसी भी हिस्से पर लागू हो सकता है?
• क्या app.service.ts, data.service.ts या helper.service.ts नाम की कोई फ़ाइल है?
• क्या shared/ का वजन किसी व्यक्तिगत विशेषता से अधिक है?

व्यायाम

GitHub पर किसी भी सार्वजनिक एंगुलर प्रोजेक्ट को खोजें - यह आपका अपना या ओपन सोर्स प्रोजेक्ट हो सकता है। कोई भी फ़ाइल खोले बिना, केवल फ़ोल्डर संरचना और नामों को देखें:

1. आप किस संगठन मॉडल का उपयोग करते हैं: सुविधाएँ या तकनीकी परतें?
2. कौन से नाम आपको संदेह या संदेह देते हैं?
3. आपको क्या संदेह है कि व्यावसायिक तर्क कहां है?
4. आपके अनुसार किस फ़ोल्डर में ज़िम्मेदारियों का मिश्रण सबसे अधिक है?
5. क्या आप किसी अन्य चीज़ को छुए बिना किसी सुविधा को हटा सकते हैं?

सत्र में आपने जो देखा उसे साझा करें और हम एक साथ मिलकर उसकी समीक्षा करेंगे जैसा कि एक वरिष्ठ वास्तुकार करेगा।

---

संकेत: 4 बिंदुओं के साथ अपने प्रोजेक्ट का विश्लेषण करें

इस प्रॉम्प्ट को कॉपी करें और इसे अपने प्रोजेक्ट के फ़ोल्डर ट्री में पास करते हुए किसी भी एआई (चैटजीपीटी, क्लाउड, कोपायलट) के साथ उपयोग करें:

---

स्तंभ 1 के इन 4 बिंदुओं को लागू करते हुए परियोजना वास्तुकला का विश्लेषण करें और एक रिपोर्ट तैयार करें।

बिंदु 1 - फ़ोल्डर संरचना

apps/ और libs/ का विश्लेषण करें और उत्तर दें:

• क्या संगठन सुविधाओं (व्यावसायिक डोमेन) द्वारा या तकनीकी परतों द्वारा किया जाता है?
• क्या आप केवल उसके फ़ोल्डर को हटाकर संपूर्ण सुविधा को हटा सकते हैं?
• क्या सुविधाओं में डोमेन नाम (checkout, catalog) या तकनीकी नाम (list, form, detail) हैं?
• क्या अस्पष्ट नाम वाले फ़ोल्डर हैं: utils, helpers, common, misc, data?
• आपको मिले फ़ोल्डरों का वास्तविक ट्री दिखाता है।

बिंदु 2 - फ़ाइल और फ़ोल्डर नाम

संपूर्ण प्रोजेक्ट और सूची खोजें:

• अस्पष्ट नामों वाली फ़ाइलें: data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils अंदर सेवाओं के साथ।
• shared/ के भीतर व्यावसायिक तर्क वाली सेवाएँ।
• core/ के भीतर घटक या डोमेन सेवाएँ।
• क्या shared/ का वजन किसी व्यक्तिगत विशेषता से अधिक है? फ़ाइल संख्या.

बिंदु 3 - वैश्विक सेवाएँ

संपूर्ण प्रोजेक्ट खोजें:

• providedIn: 'root' वाली सभी सेवाएँ - सूचीबद्ध करती हैं कि वे कौन सी हैं और क्या उन्हें किसी सुविधा के लिए स्थानीय होना चाहिए।
• गणना करता है कि कुल कितने वैश्विक प्रदाता हैं।
• विश्व स्तर पर पंजीकृत व्यावसायिक सेवाओं की पहचान करता है जब उन्हें आपकी सुविधा के भीतर होना चाहिए।
• libs/services/ में ऐसी सेवाएँ खोजें जो स्पष्ट रूप से एक विशिष्ट डोमेन से संबंधित हों।

बिंदु 4 - वैश्विक विन्यास (app.config.ts या app.module.ts)

प्रत्येक ऐप की रूट कॉन्फ़िगरेशन फ़ाइल ढूंढें और विश्लेषण करें:

• विश्व स्तर पर क्या पंजीकृत है जो नहीं होना चाहिए?
• क्या फीचर मॉड्यूल आलसी लोडिंग से भरे हुए हैं या वे सीधे आयात किए गए हैं?
• क्या वैश्विक कॉन्फ़िगरेशन में व्यावसायिक सेवाएँ हैं?
• वैश्विक स्तर पर कुल कितने प्रदाता पंजीकृत हैं?

रिपोर्ट प्रारूप

प्रत्येक बिंदु के लिए इस सटीक संरचना का उपयोग करें:

✅ क्या अच्छा है

(वास्तविक कोड उदाहरणों के साथ ठोस सूची)

⚠️ जांचने के लिए संकेत

(फ़ाइल पथ के साथ ठोस सूची और यह एक संकेत क्यों है)

❌ समस्याएँ साफ़ करें

(फ़ाइल पथ, समस्या और वास्तविक प्रभाव के साथ ठोस सूची)

अंत में इसमें शामिल हैं:

कार्यकारी सारांश

4 बिंदुओं वाली एक तालिका, एक स्थिति इमोजी (✅ ⚠️ ❌) और प्रति बिंदु एक निष्कर्ष पंक्ति।

प्राथमिकता वाले अगले चरण

स्पर्श करने के लिए फ़ाइल या फ़ोल्डर के सटीक पथ के साथ, प्रभाव द्वारा आदेशित अधिकतम 5 विशिष्ट कार्रवाइयों की सूची।

प्रत्यक्ष रहो. यह न बताएं कि कोई विशेषता या सिद्धांत क्या है। बस इस विशिष्ट परियोजना का विश्लेषण करें और वास्तविक निष्कर्ष दें।