The correct approach to the construction of architecture?
Good time of day. Would like to get advice from more experienced colleagues in terms of building architecture on the following question:
In the system there are different objects with which users interact. For example, blog articles and tickets for the administrator. 2 these object are not connected, from the point of view of code are in different modules and they have no dependencies on each other. But each of them has status (normal field in the DB). These statuses should be changed, and different roles in the system can see the objects only in certain statuses. Users can change these statuses, if it's there.
To navigate through the status, there is a separate table in the database. The General structure is this: there are some inside that are attached to one or another type of objects (workflow for your posts, for your tickets). There is a table with transactions, it specifies which status which can be transferred to the object. Is the restriction table, which indicates which role is in which status can be an accessible object.
The objective is to ensure that you need to organize a separate module that will control the status of different objects, just a question, is it right? If correct, then another question: when moving a particular object in a particular status can trigger an event. This task was planned to solve, attaching the events to the transaction (i.e., when a transition from one status to another), but also not sure if this is correct.
Maybe someone has writing experience similar, or know of good practice for such things, I would be grateful if you share. Because I have doubts about this universal approach. A similar thing is implemented in JIRA, but there is a difference is that there is only one object in the system - tasks, and then they can be infinitely many.
The example is not very good. It very much depends on the subject area. If you are developing a control system with all sorts of vakhlova, which can engage different entities, probably Yes, but then you can go to the other side - what if you select an entity class that can be used in the management of the workflow as a separate entity that can carry different payload depending on the type? Then the status attribute of this entity, and the payload will already be imposed in the components of the same Strategy...
If, as in the example you just noticed the similarity of the processes work with different entities, it is likely not to sweat. It is certainly possible to unify, but when the essence really different, sooner or later there will be differences, for the sake of the support which will have to hack their system.
At my work we have created a unified system (and Yes, there were key status) for work with different kinds of applications/the tickets/notifications, but this was preceded by a couple of years with this same functionality implemented separately.