Skip to main content

Strategic Evolution Plan: Deep Dive Blueprint

This document provides the detailed technical and functional strategies for the two upcoming modernization sessions. The goal is to decouple the Vital Core from the legacy monolith and establish a Single Source of Truth for business logic.

🏗️ Session 1: Vital Core Extraction (Technical Strategy)​

[!TIP] Detailed Proposal Available: See specs/proposals/vital_core_extraction/ for complete analysis and implementation plan.

Problem Statement​

The EITWEP.Model project is the "Anchor of the Monolith". It contains the persistence layer but is heavily coupled with System.Web, System.Drawing, and custom interfaces, preventing it from being used in a modern .NET environment.

1. The "Coupling Trap" Analysis​

The entities are generated as partial classes. Custom logic is added in EntityPartials/*.cs. Many of these partials implement legacy interfaces:

  • IWepActivityable, ICommunicable, IEITLogItemable.
  • These interfaces often depend on the very same EITWEP.Model (Circular dependency) or on legacy common libraries.

2. Implementation Blueprint (Phased Approach)​

Phase A: Abstractions Shim (.NET Standard 2.1)​

Create a new project Wep.Core.Abstractions.

  • Move non-dependent interfaces (IWepActivityable, etc.) here.
  • Any implementation detail tied to legacy DataContext must be abstracted further.

Phase B: Entity Extraction (Wep.Core.Data)​

Extract the LLBLGen-generated POCOs and the WEPV2DataContext configuration.

  • Target: .NET Standard 2.1.
  • Strategy: Use a "Data-Only" project structure.
  • Type Forwarding: To avoid breaking references in the 1M+ lines monolite, we will use:
[assembly: TypeForwardedTo(typeof(EITWEP.EntityClasses.OrderHeader))]

This allows the legacy assembly to "find" the type in the new assembly without moving the calling code.

Phase C: Logic Separation​

  • Pure Logic: Static helpers and simple getters move to Wep.Core.Domain.
  • Impure Logic: Logic depending on System.Web.HttpContext or legacy UI components stays in WepNG_MVC in the "Impure Partial" extension.

3. Mermaid Architecture Vision​

📄 Session 2: Functional Specifications Strategy (Knowledge Strategy)​

Goal​

To stop the "Archaeological Coding" (reading legacy code to understand rules) by creating a human-readable, executable-ready specification bank.

1. The Specification Workflow​

The transition follow a strict "Cleanroom" process:

  1. Code Discovery: Locate the "God Method" (e.g., PaymentsToProviderComponentService.ImportFile).
  2. Logic Extraction: Agent parses the spaghetti code to extract the underlying business rules (If/Else, Math, Validations).
  3. Gherkin Drafting: Write a .feature file documenting scenarios.
  4. Use Case Mapping: Link the Gherkin to the use_case_template.md.
  5. User Validation: The USER approves the spec as the "Source of Truth".

2. Prioritization Matrix​

We will start with the modules that are most critical for the .NET 10 Migration:

PriorityModuleReason
P0Fee CalculationTightly coupled with persistence, varies by product/country.
P1Payment ImportsHigh risk, currently using fire-and-forget async.
P2Invoicing LogicDirect impact on finance and legal compliance.
P3OMGT OrdersThe core workflow engine.

3. Deliverables per Module​

  • docs/functional_specs/[Module]/[Feature].feature (Gherkin Scenarios)
  • docs/functional_specs/[Module]/[Feature].md (Detailed Business Rules & Use Cases)
  • docs/architecture/glossary.md (Updates for domain terminology)

🚦 Next Steps Decision Point​

  1. Approve Blueprint: Confirm if this technical vision aligns with the desired evolution.
  2. Execute Session 1: Review the detailed analysis and implementation plan.
  3. Execute Session 2: Select the first "God Method" for functional extraction.

📂 Related Documents​

Session 1: Vital Core Extraction​