Given the domains that we have in our application, it is time to define the entities. When we speak of entities microservices it is important to note that any transactional need among microservices can mean a design error.
A process asynchronous message by the broker can be used to sanitize the database, but that does not mean that there is a transaction. Trying to establish a type of transaction between microservices that are completely separated may be a big mistake.
Our old application had the following entities:
News:
ID – UniqueID
Author – FK user_id
Title
Description
Content
Labels – News subjects
Type – New type (Sports, Famous, Politics)
CreatedAt
UpdatedAt
PublishedAt
Recommendations:
Label
user_id
Users:
ID
Name
Email
In addition to these entities, there is a range of tables that complement the user's information for the purpose of providing permissions and access permissions.
With the transformation of monolithic architecture for microservices architecture, the data model and design of these entities will also change.
First, we know that all the news segments will not be unique. This implies the removal of the Type:
News Service:
ID
Author
Title
Description
Content
Labels
CreatedAt
UpdatedAt
PublishedAt
Another change is that users will no longer have the responsibility for authentication and authorization.