Separation of concerns assigns each software component a distinct responsibility. Components remain independent and communicate through controlled interfaces, such as an API contract. section 3.6.2
Apply the principle by:
- Separating the frontend from the backend so each can change without unnecessarily affecting the other. section 3.6.2
- Exposing only agreed actions through an API, keeping implementation details behind the contract. section 3.6.2
- Dividing backend responsibilities among focused services instead of accumulating every action in one coordinator. section 8.3.1
A restaurant-style contract
A drive-in restaurant separates order-taking from kitchen work. The order-taker uses the menu to place requests, while the kitchen prepares matching dishes without exposing its ingredients or internal process. Replacing the order-taker or changing the cooks is possible because the menu is their shared contract. An app can use the same arrangement: the frontend requests actions through the API, while the backend handles the implementation. section 3.6.2
From one backend to focused services
A Hub class can coordinate frontend access without implementing every operation itself. UserService can handle user actions, while HaikuService handles haiku actions; a later LimerickService can be added without changing the existing services. section 8.3.1
Figure 3.13 Flow diagram for the app, highlighting the API actions
Use the app flow diagram to trace how API actions connect separated frontend and backend components. section 3.6.2
