🎭 Architecture Roundtable: The Path to Modernization
Topic: Microservices vs. Modular Monolith for WepNG Moderator: System (Antigravity)
Panelists:
- 🏗️ The Architect (Visionary, Future-Focused)
- 👴 The Veteran (Keeper of History, Risk-Averse)
- 🧐 The Critic (Red Team, Quality Guardian)
🏗️ The Architect: Friends, we are at a crossroads. WepNG_MVC is becoming unmanageable. The dependency graph looks like a map of the Tokyo subway drawn by a toddler. I propose we aggressively adopt Microservices. We need to decouple OrderFeeBiz and BO effectively immediately. Distributed systems are the only way to scale velocity.
👴 The Veteran: (Adjusts glasses) Hold on. We tried "aggressive decoupling" in 2018 with the SOAP services. Do you remember? We spent six months resolving circular dependencies and timeouts. The Monolith, big as it is, works. It compiles in one go. Transactional integrity is guaranteed by SQL Server, not by hope and prayers. If you split OrderFeeBiz, you break 15 years of implicit logic that relies on those tables being joined. You're asking for data corruption.
🏗️ The Architect: But we can't deploy unrelated changes! If Marketing wants a typo fixed, we risk breaking the Checkout. Microservices solves this!
🧐 The Critic: Stop. You're both wrong. Veteran, you’re defending a "Big Ball of Mud" that takes 20 minutes to warm up. That’s unsustainable. Architect, you’re proposing to trade "complexity of code" for "complexity of infrastructure". We don't have the DevOps maturity to manage 20 distributed services. You’ll just turn our function calls (0ms) into network latency (50ms).
🏗️ The Architect: So what? We do nothing?
🧐 The Critic: No. We do the hard thing. We build a Modular Monolith.
👴 The Veteran: A what?
🧐 The Critic: We keep the single deployment unit (so the Veteran sleeps at night). ACID transactions remain (mostly). But we enforce brutal logical boundaries inside the code (so the Architect gets their decoupling).
OMGT cannot accept BO objects. It must talk via Interfaces.
🏗️ The Architect: (Nods slowly) "Spaghetti in Tupperware". I can accept that as a transitional phase. But we need to be careful...
🧐 The Critic: "Careful" isn't enough. If we go down this road, I am putting my foot down. Choosing Modular Monolith is the easy part. Preventing it from rotting is the hard part.
Here are my 3 Non-Negotiable Demands for this architecture:
1. The "Public" Access Trap
The Critic: "The moment a Junior Engineer makes an internal class public just to 'get things done', the architecture dies. I don't trust code reviews."
- Requirement: "I want ArchUnitNET or Roslyn Analyzers in the CI/CD pipeline. The build MUST fail if Module A calls Module B without going through the Contract. If it’s not automated, it doesn’t exist."
2. Database as a Global Variable
The Critic: "Code decoupling is fake if BO is doing raw SQL Joins on OMGT tables. That’s cheating."
- Requirement: "Schema separation.
mn.Ordersandbo.Invoices. TheBOdatabase user must have DENY SELECT permissions on theOMGTschema. Is it brutal? Yes. Is it necessary? Absolutely."
3. The "God Service" Hiding Place
The Critic: "I know what you'll do. You'll create a WepNG.Shared project and dump every DTO, utility, and piece of orphaned logic in there."
- Requirement: "Immediate audit of any 'Core' or 'Shared' library. It can contain primitives and pure interfaces ONLY. If I see business logic in
Shared, I am reverting the commit."
👴 The Veteran: I... actually like the database permission idea. It stops the new guys from writing queries that lock the whole DB.
🏗️ The Architect: It restricts my velocity, but it forces the discipline we currently lack. Okay. Modular Monolith it is. But I want a Strangler Fig plan for the Frontend.
🧐 The Critic: One war at a time, Architect. Let's fix the Backend first.
Consensus:
- Strategy: Modular Monolith (Single Process, Logical Boundaries).
- Enforcement: Use CI/CD tools (ArchUnit) and DB permissions to effectively physicalize the logical boundaries.
- Next Step: Proof of Concept on
OrderFeeBizisolation.