Skip to main content

🎭 The Critic vs. The Architect: The "WepNG" Modernization Debate

Setting: A dimly lit virtual war room. The WepNG_MVC codebase looms on a holographic display, its dependency graph resembling a plate of spaghetti dropped from a considerable height.

Characters:

  • The Architect 🏗️: Visionary, focused on scalability, decoupling, and long-term maintainability. Wants to break the chains of the legacy system.
  • The Critic 🧐: Pragmatic, cynical, obsessed with operational costs, latency, and "Murphy's Law". Believes "complexity is the enemy".

The Architect: (Gesturing to the OMGT module blink-rate on the screen) Look at this. Every time we touch OrderFeeBiz, the BO module shudders. We can't keep patching this monolith. The team is stepping on each other's toes. We need to talk about Microservices. The industry standard. Complete decoupling.

The Critic: (Sips coffee, unimpressed) "Industry standard" is sales-talk for "we want to update our CVs". We have a .NET MVC legacy application here, not Netflix. You want to take a system where a function call takes 0.01ms and replace it with a network call that takes 50ms, plus serialization, plus discovery, plus inevitable failure?

The Architect: It's not about speed, it's about velocity. Deployment boundaries! Right now, to fix a typo in the Order Fees, we redeploy the entire platform. If we carve out OrderFeeBiz as a standalone gRPC microservice...

The Critic: ...Then you introduce Distributed Transactions. Suddenly, creating an Order isn't a simple SQL transaction with ACID guarantees. It's a Saga. You'll need an orchestrator, or choreography. You'll strictly need to handle Compensation events when the Fee service charges the card but the Inventory service fails. Are you ready to explain "Eventual Consistency" to the Finance team? "Don't worry, the report will balance... eventually."?

The Architect: You're catastro-sizing. We wouldn't microservice everything. Just the core domains. The Strangler Fig pattern is already in our Strategic Patterns document. We peel off the edges.

The Critic: Strangler Fig is fine. But peeling off an edge into a separate process requires infrastructure maturity we haven't benchmarked yet. Do we have standard observability? Distributed tracing? If a request fails, can you instantly tell me which of the 15 containers timed out? Or will we spend 3 days grepping logs across 4 different clusters?

The Architect: So what? We do nothing? Watching the "God Objects" grow until the WepNG.dll exceeds the GitHub file size limit? We need boundaries. Hard boundaries.

The Critic: I agree on boundaries. I disagree on the implementation of those boundaries. I propose a Modular Monolith.

The Architect: (Scoffs) Fancy words for "Spaghetti in Tupperware".

The Critic: No. Enforced Tupperware.

  1. Logical Isolation: We use .NET mechanisms (solution folders, internal keywords, Roslyn analyzers) to forbid cross-module calls except through public Contracts/Interfaces.
  2. Single Deployment Unit: We keep the deployment simple. One artifact. No network latency between calls. ACID transactions still work within the database (mostly).
  3. Future-Proof: If—and only if—one module (say, OrderFeeBiz) actually hits scaling limits, then we can peel that one specific Tupperware container out into a Microservice.

The Architect: (Pauses, looking at the executive_summary.md) The docs do mention "Modular Monolith" under Architectural Decisions... But if we keep the database shared, we're still coupled. The Data Schema is the ultimate coupling.

The Critic: Correct. That's the hardest part. In a Modular Monolith, we must treat the Database as private to the module. OMGT cannot join tables with BO. It must ask BO for data via an in-process API.

The Architect: In-process calls... high performance, strict contracts. And if I want to deploy just the MNT module?

The Critic: You can't. That's the trade-off. But do we really deploy MNT alone? Or do we deploy the platform? Let's be real: The cost of "The team cannot deploy independently" is currently lower than the cost of "The team cannot debug why the OrderCreated event vanished in the message broker".

The Architect: ...Fair point. The "Quality First" methodology demands stability. So the plan is:

  1. Refactor into a Modular Monolith first.
  2. Strictly enforce boundaries (internal vs public).
  3. Decouple the Data Layer (stop cross-module SQL joins).
  4. Reference the "Strangler Fig" only if we specifically identify a performance bottleneck that needs independent scaling.

The Critic: Exactly. Slow is smooth, smooth is fast. Don't build a Ferrari engine for a station wagon before you've fixed the transmission.

The Architect: Agreed. I'll update the ADR. We are going Modular Monolith.

Key Takeaways for WepNG:​

  • Verdict: Modular Monolith is the safer, more pragmatic choice for the current modernization phase.
  • Focus: Enforce logical boundaries (Namespace/Assembly level) and Data isolation first.
  • Risk Mitigation: Avoids the operational complexity of distributed systems until absolutely necessary.

🕵️ Post-Debate Analysis: The Critic's Follow-up​

Our Critic (defined in AGENTS.md as "Strategic Challenger" and "Red Team") would not be satisfied with a theoretical victory.

After convincing the Architect to avoid Microservices, their job isn't finished. Now they would attack the implementation of the Modular Monolith to prevent it from becoming a "Big Ball of Mud" in disguise.

Here is exactly what they would say, activating their Red Team/Skeptic mode:

🕵️ The Critic's Intervention​

"Alright, we avoided the operational suicide of Microservices. Well done, everyone. But don't pop the champagne just yet.

Choosing the Modular Monolith is the easy part. Maintaining the discipline to prevent it from rotting is the impossible part for this team, unless we put steel guardrails in place today.

Here are the 3 ways this plan will fail within 6 months if we don't intervene:

  1. The Illusion of Decoupling (The Indiscriminate "Public")

    • Risk: As soon as a junior developer is in a rush ("Business is waiting!"), they will make an internal class of OMGT public to use it in BO. In that moment, modularity dies.
    • Requirement: I don't trust code reviews. I want ArchUnitNET or Roslyn Analyzers in the CI/CD pipeline that fail the build if module 'A' touches module 'B' without passing through the public Contract. If it's not automated, it doesn't exist.

  2. The Database as a "Global Variable"

    • Risk: At the code level we are clean, we use interfaces. But underneath, in the database, BO does a brutal JOIN on OMGT tables because 'it's more performant'.
    • Requirement: DB Schema Separation. I want distinct SQL schemas (mn.OrderTable, bo.InvoiceTable). And the DB user for the BO module must have DENY SELECT on the OMGT schema. Brutal? Yes. Necessary? Absolutely. Otherwise, we are just pretending.

  3. The Hidden "God Service"

    • Risk: We create a WepNG.Shared or WepNG.Core project and dump everything we don't know where to put into it (DTOs, Extension Methods, 'Common' Business Logic).
    • Requirement: Immediate audit of any 'Shared' project. It must contain only primitives and pure interfaces. If I see business logic in Shared, I will revert the commit.

In summary: The Modular Monolith works only if we are encapsulation fascists. Otherwise, we have just built a monolith that is more complicated to navigate. Are you ready to fail builds for a namespace violation?"

Note: The Critic is rigorously applying the "Quality Guardian" principle defined in the Agent Registry, shifting focus from strategy (what to do) to defensive tactics (how to avoid doing it poorly).