Separate domain and transport

Start from the behavior you can observe. A note service owns title rules and ownership, while the router owns params, status codes, and representations.

Routes translate HTTP into domain calls and domain outcomes back into HTTP; they should not contain every business rule. The useful target is not encyclopedic coverage. Make one deliberate choice, observe its consequences, and know which requirement would make you revise it.

It is tempting to pass Express request objects deep into the data and domain layers. That trades a clear decision for an assumption you will eventually have to debug. The stronger move is to define plain inputs and outcomes at the boundary and inject dependencies into app construction. Make the boundary explicit in code and in the project notes.

Tie the decision back to the larger job: Ship the notes app with black-box tests, production controls, and a failure matrix that can be rerun after changes. Record enough evidence that another developer can repeat the result without relying on your memory.

Move one complicated route rule into a plain function and compare the resulting route and domain tests. Repeat it once with an invalid or hostile condition and write down the boundary the failure revealed.