Skip to main content

MNT Module Analysis: Maintenance & Masters

1. Overview​

MNT (Maintenance) handles Master Data management for the WepNG platform. It controls the "static" data that drives the business (Products, Countries, Currencies).

Key Metrics (Estimated)​

  • Scope: Country, City, Currency, Product, Pricing.
  • Structure: Highly granular. Contains 27+ sub-business areas (e.g., CityBiz, Currency).
  • Complexity: Medium logic, but High Volume of diverse entities.
  • Criticality: High. Pricing and Product definitions drive OMGT and Selling.

2. Architectural Archeology​

2.1 The "Siloed Managers" Pattern​

Unlike CRM or OMGT which rely on massive Services, MNT seems to follow a Siloed Manager pattern.

  • Observation: Logic is split into specific "Biz" folders (CityBiz, CountryMNTBiz).
  • Pros: Better Separation of Concerns than CRM.
  • Cons: Can lead to fragmentation if cross-entity rules (e.g., Product pricing depending on Country) are not well orchestrated.

2.2 The "God Class" Risk (ProductBiz)​

ProductBiz is a large directory with 30 sub-items.

  • Risk: Product definition in WEP is notoriously complex (High School, Jobs, Languages). If ProductBiz tries to unify all these under one polymorphic umbrella without proper Strategy Pattern, it will be a maintenance nightmare.

3. Practices Analysis​

3.1 Bad Practices​

  1. Export/Import Complexity:
    • ExportBiz (22 items) suggests a heavy reliance on CSV/Excel exports for business operations, likely a workaround for a poor UI or lack of API integrations.
  2. Hardcoded Rules in Masters:
    • (Hypothesis based on WepMNTService.cs small size): If the Service is thin, business rules might be buried in the "Biz" classes or, worse, in ExportBiz logic (transforming data on the fly).

3.2 Best Practices (Target)​

  1. Cache-Aside Pattern:
    • Master data (Countries, Currencies) changes rarely. Implement robust Caching (Redis/MemoryCache) for these read-heavy entities.
  2. Strategy Pattern:
    • For ProductBiz, ensure different product types (School vs Job) use specific Strategies for Pricing and Validation, rather than a giant switch statement.

4. Evolution Strategy​

Step 1: Caching Layer​

Implement a caching decorators for CountryReader, CityReader, etc., to reduce DB load.

Step 2: Product Catalog Bounded Context​

Extract ProductBiz, PricingBiz, FeeBasePriceBiz into a dedicated Product Catalog Bounded Context. This is distinct from "Maintenance" and deserves its own lifecycle.