Problem
Succession::Model currently combines several different responsibilities:
- DBIx::Class queries and page view data;
- genealogy graph management;
- remote blog-feed fetching and fallback caching;
- shop JSON loading and HTTP validators;
- reference Markdown menu discovery;
- diagnostics and curated historical data.
The file has now been organised and documented, but its size and dependency surface will continue growing if every data-related feature lands there.
Proposed work
Extract responsibilities incrementally rather than in a large rewrite. Good first candidates are the isolated, non-database services:
- blog feed fetching/caching;
- shop JSON loading;
- reference-menu discovery.
Keep route-facing behaviour stable and inject the extracted services so their existing tests remain deterministic.
Acceptance criteria
- Agree a small service boundary and naming convention before extraction.
- Extract one responsibility at a time with no route behaviour change.
Succession::Model trends toward database/domain operations rather than generic application I/O.
- Existing feed, shop, query-budget, and full-suite tests continue to pass after each extraction.
Problem
Succession::Modelcurrently combines several different responsibilities:The file has now been organised and documented, but its size and dependency surface will continue growing if every data-related feature lands there.
Proposed work
Extract responsibilities incrementally rather than in a large rewrite. Good first candidates are the isolated, non-database services:
Keep route-facing behaviour stable and inject the extracted services so their existing tests remain deterministic.
Acceptance criteria
Succession::Modeltrends toward database/domain operations rather than generic application I/O.