A web service receives a request, applies business logic, fetches external data, applies more business logic, and returns a response. The rules belong in the foreground; collection mechanics should not obscure them. section 11.2 section 14.0
Keep business logic readable by following a few deliberately unfashionable rules:
- Separate domain rules from the internal details of manipulating data. section 14.0 section 14.5
- Hide low-level operations such as reduce behind a narrowly named utility function. section 14.3 section 14.5
- Design complicated utilities by discovering their signature, writing a unit test, stating behavior plainly, and implementing them. section 14.5
Make lendingRatio say what it means
A lendingRatio function first flattens nested book items, then calls countByBoolField to count lent and not-lent items, and finally calculates the ratio. The business code names the rule instead of exposing iteration and accumulator updates. The utility itself can be unit-tested independently.
Figure 11.3 Building the insides of our systems like building the outsides. The inner components of a web service communicate with data. As an example, here is a typical flow of a web service handling a client request: (1) Parse the client JSON request into data. (2) Manipulate data according to business logic. (3) Serialize data into a JSON request to a database and another Web service. (4) Parse JSON responses into data. (5) Manipulate data according to business logic. (6) Serialize data into a JSON response to the client.
Trace how data-oriented components parse, transform, serialize, and reapply business logic across a web-service request. section 11.2
