Backend And Business Logic Design
Definition
Design the server-side behavior that enforces the feature's rules and state changes. Keep business logic in owner modules, not scattered through routes, UI, or persistence adapters.
Questions To Ask
- What command or use case performs the feature?
- What rules and permissions must it enforce?
- What data is read and written in one transaction?
- What side effects happen, such as notifications or jobs?
- What should be idempotent, retried, or blocked?
Existing Project Comparison
- Inspect services, commands, route handlers, domain modules, permissions, jobs, and tests.
- Identify duplicated business logic and move it toward the owner.
- Check existing transaction and error-handling patterns.
Suggestive Plan
- Define the backend use case.
- Order rule checks, permission checks, data reads, writes, and side effects.
- Define transaction boundary.
- Define domain events or notifications.
- Map each behavior to tests.
Example
changePreferredWindow verifies actor permission, checks request is pending, validates the window, writes the change, and emits AppointmentRequestUpdated.
Vocabulary
- Use case: backend operation that completes a feature action.
- Business logic: rules and decisions that define correct behavior.
- Transaction boundary: work that succeeds or fails together.
- Side effect: behavior outside the core state change.
Expected Outcome
Produce backend design with use case flow, owner module, rules, transaction boundary, side effects, and test mapping.
1---2name: backend-and-business-logic-design3description: Design backend flow and business logic for one feature. Use when deciding commands, transactions, domain rules, permissions, side effects, jobs, and module ownership before coding backend behavior.4---56# Backend And Business Logic Design78## Definition910Design the server-side behavior that enforces the feature's rules and state changes. Keep business logic in owner modules, not scattered through routes, UI, or persistence adapters.1112## Questions To Ask1314- What command or use case performs the feature?15- What rules and permissions must it enforce?16- What data is read and written in one transaction?17- What side effects happen, such as notifications or jobs?18- What should be idempotent, retried, or blocked?1920## Existing Project Comparison2122- Inspect services, commands, route handlers, domain modules, permissions, jobs, and tests.23- Identify duplicated business logic and move it toward the owner.24- Check existing transaction and error-handling patterns.2526## Suggestive Plan27281. Define the backend use case.292. Order rule checks, permission checks, data reads, writes, and side effects.303. Define transaction boundary.314. Define domain events or notifications.325. Map each behavior to tests.3334## Example3536`changePreferredWindow` verifies actor permission, checks request is pending, validates the window, writes the change, and emits `AppointmentRequestUpdated`.3738## Vocabulary3940- Use case: backend operation that completes a feature action.41- Business logic: rules and decisions that define correct behavior.42- Transaction boundary: work that succeeds or fails together.43- Side effect: behavior outside the core state change.4445## Expected Outcome4647Produce backend design with use case flow, owner module, rules, transaction boundary, side effects, and test mapping.
harsh817