Hi Francesco, how you formulate and present information is inspiring. So simple and straightforward. I like it a lot and love to absorb such a material.
As regards SRP, both compositions under "No" and "Yes" examples are not violating the principle. They compose two things — validation and creation of the user. This function isn't an operation. It's a composition. Operations are testForm() and createUser(). They shall comply with SRP. And the composition composes operations, it's a control flow.
How about to rename validateRequest() function to something like createValidUser() in favor to clarify composition happening within?
What both examples violate is DIP, the last one from SOLID. Because they compose testForm() function and createUser() which become direct dependencies. We can't exchange them, if we need to run a different validation, for example.
To comply with DIP, we could inject them both into a composition.
createValidUser = (req: Request, validate: ValidateForm, createUser: CreateUser): void => {
const { name, password, email } = req.body;
if (validate(name, password, email)) {
createUser(req);
}
throw new Error…
}
Voilà, now our composition createValidUser() function would depend on interfaces, not on implementations details.
When composition composes various operations it doesn't violate SRP. It contains a control flow of a program, which developers maintaining this code could clearly understand without looking at the implementation details of operations being composed.