How to properly process requests in a business application?

Question

Java

A question has come up.
In my view, processing a request in a business application is divided into steps:
1. syntax check of the request data,
2. check for the existence of the objects mentioned in the request,
3. loading these objects from various storages,
4. checking the consistency of these objects (for example, Order belongs to that Store, etc.),
5. carrying out some meaningful business actions,
6. forming a response.
In addition to this sequence (the so-called main successful scenario?), you also need to
a) log system actions
b) handle errors
c) store information about the request in some kind of storage
For obvious reasons, if an error occurs at any stage, the system would, firstly, generate a correct and maximally detailed business response (HTTP 500 is not an answer, it is an accident), and secondly, record the “fallen” request in the storage as detailed as possible (so that later those support would see the problem in their interface).
If we consider the code of such an application, it should be understandable, easily maintained, extensible, etc. (I'm not sure I fully understand the meaning of this "etc.").
My practice shows that during development it is very easy to "fall" into a leapfrog of exception handlers, conditions, log entries. A bunch of duplicated code, low content of semantic code (for one line of semantic action we have 3-10 lines of error handling).
Question: how to properly organize the application within these requirements? What to read?

Answer 1

Use a repository that stores only consistent data
Send logs to files
Aggregate logs and check regularly

Answer 2

TDD and an iterative approach to development. I advise you to read the book Object-Oriented Analysis and Design on this topic .

Answer 3

Disclaimer: This is just my experience and my opinion.
I would recommend reading in general about the architecture of Web / Enterprise applications, and pay attention to the four-layer architecture (layers: views, services, business, dao). I did not find a picture and description of this architecture, but each layer can be googled. It’s worth clarifying right away that a layer and a level are not the same thing.
For study, you can also look at reports from video conferences, for example:
I also saw the description of Skyforge architecture .
If you look at your steps, then I would arrange the responsibilities as follows:
1) (?) application server (if I understand correctly)
2) service layer
3) dao
4) consistency to services
5) business layer
6) views
Additional properties are provided using aspects (logs, security).
Error handling, I would call exception handling, occurs generally in a separate place, and it does not belong to any layers, but rather is also provided by aspects.
In order to be "understandable, easily maintainable, extensible, etc." it is necessary, oddly enough, to follow the rules of Clean Code, etc. (see OOP paradigms above).