Case category · Engineering & architecture
5 cases Category 2 of 20
This band connects code structure and engineering process: splitting legacy modules, generating readable changelogs for release trains, auto-triaging issues and PRs, database migrations with rollback, and bounded-context style service boundaries. Pair with CI/CD, architecture, and collaboration skills to turn one-off discussions into repeatable playbooks.
In the case hub it is Engineering & architecture (#cat-eng), next to R&D & quality and leaning toward system-level, cross-repo work; each case still needs explicit triggers and completion criteria.
Module boundaries, dependency direction, interface convergence, incremental refactors.
Change summaries, release notes, rollback notes, audience-specific versions.
Label policy, templates, routing rules, automation conditions.
DDL/DML, lock risks, rollback SQL, verification steps.
Domain boundaries, event contracts, data ownership, anti-corruption layers.
Find cycles and god modules; propose packages and dependency direction (stable core, adapters outward); use strangler patterns or interface seams so each step keeps the build green without long-lived branches.
Aggregate merges, tickets, or change records into customer-visible vs ops-only deltas; produce versioned release notes, rollback hints, and known issues with separate blurbs for end users, support, and SRE.
Define label semantics and priority rules; combine templates and title keywords for label suggestions or automation; keep a fallback path for human triage when confidence is low.
Separate reversible vs irreversible DDL, assess lock risk and wide-table rewrite windows; pair each forward step with rollback SQL and data checks, aligned with blue/green or canary releases.
Partition services and data ownership with domain language; clarify sync APIs vs async events; mark anti-corruption layers and shared-kernel risks to avoid a distributed big ball of mud.