Surgery on a Beating Heart

EVEMon.Common. 846 files. 83,656 lines. One assembly. Seventy-five directories.

Everything lived together: interfaces, encryption, email, in-game browser, serialization, Windows controls, skill math, character models, settings — all compiled as a single unit.

For non-engineers: imagine a warehouse with no internal walls. Kitchen, bedroom, bathroom, and garage are all one room. Change the plumbing, risk the electrical. Replace the carpet, and you might move the refrigerator. That's what working in EVEMon.Common was like.

In practice: the skill planning logic imported Windows UI types. The market order models imported image-drawing libraries. The settings system called MessageBox.Show() directly from service code. Seven character model files had Windows-only image types baked into the domain layer.

You couldn't extract the scheduler into something testable because it was tangled into the same assembly as the Windows screen code. And you couldn't test the screen code because it was tangled into the same assembly as the settings code. Everything touched everything.

I designed six assemblies forming a strict hierarchy — dependencies only flow downward, never up, never sideways:

EveLens.Core           →  Interfaces only. Zero dependencies. The constitution.
  ↓
EveLens.Data           →  Enums, constants, static game data.
  ↓
EveLens.Serialization  →  API response formats, settings file formats.
  ↓
EveLens.Models         →  Characters, Skills, Plans.
  ↓
EveLens.Infrastructure →  EventAggregator, logging, scheduling.
  ↓
EveLens.Common         →  Services, settings, ViewModels.

464 files extracted from Common. Each layer has one job.

The original codebase had 21 interfaces total, and zero of them were service interfaces. Zero IEventAggregator. Zero IDispatcher. Zero ISettingsProvider. The entire architecture relied on EveMonClient as the sole point of access for everything.

EveLens.Core defines 27 service contracts. Any project in the stack can depend on Core without pulling in anything else. This is what makes the scheduler testable — it depends on interfaces, not on the Windows UI.

You can't stop the world while you rearrange 846 files. The application needed to keep working after every step.

I moved files one category at a time. Interfaces first — they became EveLens.Core. Then enums and constants became EveLens.Data. Then serialization DTOs. Then models. Then infrastructure.

Each move was a separate commit. Each compiled. Each was tested. When a move created a circular dependency — file A needs file B, but file B also needs file A — I had to extract an interface from one of them and break the cycle.

The key commit that landed the split:

19ed6784 — Project Phoenix: 6-assembly split of EVEMon.Common (356 files extracted)

356 files physically moved from one project to six. One commit. Everything still compiles.

During the split, things kept going wrong in predictable ways. A developer (or an AI) would instinctively put a file back in Common because that's where "everything goes." An interface would grow a Windows dependency. A service would grab a static reference instead of using injection.

I codified the patterns into fourteen rules — Architectural Laws — and wrote tests to enforce every one:

1. No static mutable state — use AppServices and interfaces
2. No god objects — no class over 500 lines or referenced by over 30 files
3. Dependencies flow downward only — enforced by automated tests
4. New services must be testable — constructor injection, interfaces, test doubles
5. Events through EventAggregator only — no static events, ever
6. Lazy by default — constructors must be fast
7. No sync-over-async — never .Wait() or .Result except in bootstrap
8. Right file, right assembly — interfaces in Core, enums in Data, DTOs in Serialization
9. EveMonClient is frozen — never add to it, only subtract
10. All async void must have try/catch — WinForms requires async void for handlers
11. Event subscriptions must be disposed — store the disposable, dispose on close
12. Tests prove behavior — no feature without a test, no bug fix without a regression test
13. Serialization DTOs are the data contract — changes require round-trip tests
14. No direct EveMonClient access from UI — use AppServices

Each law has corresponding automated tests. Assembly boundary tests use cycle detection on the actual assembly references at runtime — if someone introduces a circular dependency, the build fails and tells them exactly which path creates the cycle.

32 architecture enforcement tests total. The architecture can't regress because the tests won't let it.

The monolith had walls. The foundation was set. The scheduler — the thing that started this whole journey — could finally be isolated, tested, and rebuilt.

Previous: Part 3 — The God Object Has 69 Static Events

Next: Part 5 — The Scheduler Was Broken All Along