Domain Logic Pattern Selector

Choose between Transaction Script, Domain Model, and Table Module for a subsystem, then decide how thick to make the Service Layer. Based on Fowler's Patterns of Enterprise Application Architecture (Ch 2 + Ch 9).

When to Use

Use this skill when starting or refactoring a subsystem and the central question is: how should business logic be organized? This is distinct from where that logic persists (data-source patterns) or how it is presented.

Typical triggers: greenfield module design, Transaction Script code growing unmanageable, a team debate about "should we use DDD?", evaluating whether to add a service layer, diagnosing anemic domain model or script sprawl in legacy code.

Prerequisites: none. Works from a verbal description of the subsystem; codebase access improves diagnosis.

Context & Input Gathering

Ask the user (or read from codebase) in this order: