Domain Logic Pattern Selector

Scenario A — Revenue Recognition Engine (Complex Rules → Domain Model)

Trigger: A team building a SaaS billing system. Revenue recognition rules vary by product type: word processors recognize 100% immediately; spreadsheets spread recognition over three dates; databases over two; and the CFO adds new product categories quarterly.

Process:

Output: Domain Model with Contract, Product, RevenueRecognition, and a strategy hierarchy (CompleteRecognitionStrategy, ThreeWayRecognitionStrategy). RecognitionService is an Operation Script service layer that delegates domain logic to domain objects and handles email/integration notifications.

Scenario B — Simple Order Management (.NET CRUD → Table Module)

Trigger: A .NET team building internal order management. Rules are mostly: validate fields, calculate totals, apply standard discounts. All UI is data-grid based. ADO.NET DataSets flow through every layer.

Process:

Output: Contract Table Module, Product Table Module, RevenueRecognition Table Module operating on a shared DataSet. No domain object identity — every operation takes a primary key parameter.

Scenario C — Legacy Transaction Scripts Hitting Complexity Wall → Refactor to Domain Model

Trigger: A Java team's billing service has grown to a 2,000-line BillingService class. Discount logic is copy-pasted across five methods. Adding a new rule requires touching seven places.

Process:

Output: Decision record documenting the refactor direction, a domain object skeleton (Contract, LineItem, Discount), BillingService reduced to coordinating transactions and notifications, and a Data Mapper recommendation for persistence.