Where to find patterns of the "correct" parts of the system?

Question

PHP

The question sounds stupid, but I'll try to decompose.
Here are the design/programming patterns. It’s easier with them, it’s just that in most cases you already know what pattern can be inserted into one or another part of the program and it will be good.
Here, designing a large project from scratch, you already operate not with pattern objects, but with parts of systems that consist of pattern objects. For example, there are many places where you need authorization, access rights, work with entities (editing products, categories in the admin panel, etc.). All this in most projects is in total very similar, that is, one solution would be useful here and there and in many other places. So people got to RBAC , or if you need user authorization without obtaining a password, then OAuth will do., well, for logging for almost all occasions, PSR-3 will fit (for php)
At its core, these are the principles of subsystems in one large system, something like best practice.
Actually the question is: is there a collection of all these best practices?

Answer 1

Here, when designing a large project from scratch, you already operate not with pattern objects, but with parts of systems

Patterns are what should be the output, they are not designed. It's just that you can, for example, tell your colleague "listen, to check the rights to perform actions here, perhaps RBAC is too primitive and inconvenient ... let's file down the waterer mechanism - a stupid chain of responsibilities that returns Yes, no or I don't know" and the colleague will understand how it should be to look like. And do not try to shove the pattern just like that.
Large projects start designing from a higher level. First, they make a decision about what kind of layering we will have (for projects with a lifespan of ~10+ years, it makes sense to drive ahead and introduce a hexagonal architecture, for projects with lifespans <= lines of framework support, you can not worry too much), which components can be isolate, and only then split these large components into smaller components.
Then you can start designing each individual component at the class level.
Also, if we have a complex subject area, they design a model of the subject area. Usually here "patterns" by themselves turn out stupidly with a decrease in connectivity between objects.
> Actually the question is: is there a collection of all these best practices?
Out of context, there are no best practices, there are just practices. In this regard, you can read Fowler, for example, he describes practices very well, their pros and cons.
In general, I would recommend that you get to know the principles of SOLID and GRASP better. Few people know the latter, but understanding, for example, what high engagement is, greatly affects how you design the system.

Answer 2

Вы ищите то, чего нет. Нет понятия "правильных" частей системы, или "правильных" паттернов.
Вот вам пример: OAuth, что вы привели имеет 2 версии, это что получается, первая была не правильная?))
RBAC - это подход, который далеко не всегда уместен, часто его проще и лучше заменить ACL (безусловно, это не всегда так).
PSR-3 - это не совсем паттерн, это скорее рекомендуемое соглашение.
Конкретно по php миру: рекомендую реализовывать следующие требования, проникнуться Symfony way, активно использовать паттерны: DTO, VO, код писать вместе с тестами (вот это капец как критично для крупных систем).
Что касается более высокоуровневых паттернов, в стиле OAuth, RBAC - они вам потребуются только в случае, если это требуется бизнесу, для которого вы пишете систему.

Answer 3

В голову приходит такое: https://habrahabr.ru/company/zfort/blog/279163/