Solution Design
From PDD to SDD
Solution design translates the business-facing PDD into a technical SDD. It must cover the process decomposition, object model, work queue design, exception strategy, credential handling, environment topology, and non-functional requirements such as throughput and availability.
Design principles
Favour reusable objects and process layering: a main process orchestrates, page-level processes handle stages, and objects handle application interaction. Keep business logic in processes and technical interaction in objects. Avoid monolithic processes; decompose by business function and by exception behaviour.
Traps
A frequent trap is designing one object per screen rather than one object per application with a coherent interface. Another is burying business rules inside an object, making them untestable and hard to change. Questions may ask where retry logic belongs: it belongs around the action that can fail, usually in the process or a dedicated resilience page, not scattered inside object actions.
Non-functional design
Design must state expected volumes, peak concurrency, acceptable latency, and recovery objectives. A design that ignores peak load is a common wrong answer.
Rule of thumb
If a design decision cannot be traced to a PDD requirement or a non-functional constraint, it is probably gold-plating.
Worked example
A claims process touches three systems and must handle 500 cases per hour at peak. Design one object per system, a queue-driven main process, a separate exception-handling page, and a capacity estimate showing workers needed at peak versus average.