Entities architecture in Doctrine, Symfony 4 - who can help?

Question

symfony

Hello everyone,
There are three projects that are fundamentally similar to each other.
At least some entity. How to build an Architecture so that these entities can be used in all projects.
There were several ideas:
1. Use Traits, but it's somehow not right.
2. Create an abstract Class and inherit, but there is one thing, you can inherit only once ... the projects are still slightly different. Somewhere you need a relation and where not. Or in some places relation m:n and in some places vice versa.
Tell me how you do in these situations?

Answer 1

There is such a thing as a subject area (Domain). The domain consists of models (in Doctrine it is Entity), domain services, and much more.
As far as I understand from your comments, you have 3 interfaces (UI) that work with a single subject area. In this case, there is no need to duplicate business logic for each interface. It is more correct to separate the business logic into a separate entity and reuse it in your applications with interfaces.
You can organize the code of your business logic into an independent module, take it out in the Composer package and arrange it as a Symfony Bundle, which you did.
If you have several independent projects / sites that have a similar subject area with slight differences, then I recommend not using one business logic implementation for all projects and I recommend duplicating the code in all projects.
Let me explain. At first, on small projects, it seems like a good idea to reuse code, but over time, projects develop and they tend to evolve independently of each other. With the development of individual projects, the business logic of the corresponding projects may, and most likely will change, and you will have to make changes to a single code for all projects. Thus, the changes will be applied not only in the project where they are needed, but also in other projects that do not need these changes. This can break the business logic of other projects, lead to conflicts and unexpected errors. This approach has the right to life, but you need to assess the risks and carefully weigh everything. My practice has shown that this does not lead to anything good.