Is it the right approach to architecture building?

Question

MySQL

Good day. I would like to get advice from more experienced colleagues in terms of building architecture on the following issue:
There are different objects in the system that users interact with. For example, blog articles and admin tickets. 2 of these objects are not related in any way, from the point of view of the code they are in different modules and they do not have any dependencies on each other. But each of them has a status (a regular field in the database). These statuses must change, and different roles in the system can see these objects only in certain statuses. Users can change these statuses, if possible.
There are separate tables in the database to navigate through the statuses. The general structure is as follows: there are certain workflows that are assigned to one or another type of object (its own workflow for posts, its own for tickets). There is a table with transactions, it indicates from which status an object can be transferred to. And there is a table of restrictions, which indicates which role in which status an object can be accessed.
The task boils down to the fact that you need to organize a separate module that will manage the statuses of different objects, the question is immediately, is this right? If correct, then another question: when a certain object passes to a certain status, some event can be triggered. This task was planned to be solved by attaching an event to a transaction (that is, when a transition occurs from one status to another), but I'm also not sure if this is correct.
Maybe someone has experience writing something like this, or know good practices for such things, I will be grateful if you share. Because I have doubts about the correctness of such a universal approach. A similar thing is implemented in JIRA, but the difference is that there is only one object in the system - tasks, and here there can be an infinite number of them.

Answer 1

The example is not very good. This is highly domain dependent. If you are developing a system for managing all kinds of workflows in which different entities can participate, then probably yes, but here you can go from the other side - what if you select a class of entities that can be used in workflow management as a separate entity that can carry different payloads in depending on the type? Then the status will be an attribute of this entity, and the payload will already be transferred to the components of the same Strategy...
If, as in the example, you just noticed the similarity of the processes of working with different entities, then most likely you should not worry. You can, of course, unify, but when the entities are really different, sooner or later there will be differences, for the sake of supporting which you will have to hack your own system.
At my work, we created a unified system (and yes, statuses play a key role there) for working with all kinds of requests / tickets / notifications, but this was preceded by a couple of years of working with the same functionality, implemented separately.