How to develop atypical architecture?

Question

OOP

Let's say there is a typical project - CRM, online store, SEDO. If a person has used something like this at least once, then he already has a good idea of ​​what entities are and how to describe them in code. If a person has never used it, then it is usually quite easy to google what are the typical components for a project. But sometimes it happens that the project is non-standard, it can be either something in between several typical ones, or in general something unique enough to write fundamental things from scratch. Actually, any sources of information where one could peep the following are interesting:

• What questions to ask the customer, what to focus on
• Working out abstractions for entities
• Actually mapping entities into code
• Prevention of bottlenecks in the future, refactoring

It is desirable in the context of any modern PL, so that you can look at the code. Ideally, this is something like when a person tells what kind of project he had, what was the basic TOR, how he reasoned, what he did, how the TOR changed, what things he did right, what wrong, why and what should be paid attention to in the future.

Answer 1

In my opinion, such materials do not yet exist and are not even expected. Such an experience is hard to formalize. In general, almost nowhere they teach “how to solve problems” :-)
From a non-programming, but engineering, I can advise you to get acquainted with TRIZ (Theory of inventive problem solving). Most of the approaches described in it are commonly used.
You can also read The Phenomenon of Science. Cybernetic approach to evolution.

Answer 2

I believe that when designing non-standard components of a project, one should pay attention to the subject area. As you wrote in the question, with typical components, information about the subject area is available and, in some cases, an implementation of the subject area is available that you can spy on. And when the subject area has not yet been studied, then the best advice would be to study the subject area and discuss with the customer what representation the fragments of the subject area will have.
The development of abstractions for entities, the mapping of entities in non-typical cases come from the subject area, and the pitfalls and future refactoring most often come from the quality of working out and understanding a non-trivial subject area.
As literature, I think any literature about development through the subject area (DDD) is suitable here.