Introduction
MySQL is well known for Enum data type with some predefined
values. If we try to insert or update any custom values, we will get exception.
Coming to MSSQL we will not have any equivalent data type for MySQL Enum. In
monolithic architecture-based applications, it is fine to have code based Enums
inside the applications and store their values in database TINYINT data type
fields since we will have business layer as intermediate between presentation
layer and database layer. We are in new era of microservice architecture-based
applications. It is not good to have Enums inside the code base since single
application may have fine grained services and each service will have their own
domain layer. In such cases we may need to duplicate the code based Enum inside
service which may bring maintenance nightmare. For this problem we will
introduce the look-up tables as solution which will act like Enum, and it will
have its own key-value pair records.
Sample Use Case
Let us consider my online store is an application which
is built on the top of microservice based architecture. Consider we will have
- User management service
- Item Management service
- Stock Management service
- Order Management service
- Notification Service
- Item Ordered
- Item Shipped
- Item Delivered
- Item Canceled
- Item Rejected
Enum Structure
Enum has read only key value pair structure and for this use
case we will have Enum structure like
Enum Based Approach
Since we need to notify user about an ordered item. We need
to place OrderStatusEnum, mostly in all microservices like
- Item Management service
- Stock Management service
- Order Management service
- Notification Service
Drawback in Enum based approach
- Code is repeated in all services
- Violating microservice for independent development and deployment. Because every team should need to have awareness about order status Enum.
Another Problem
We have some drawback in above mentioned Enum approach, so if
we planned to place Enum in database level. We will again have data store for
each microservices and, we don’t have any data type to store Enum in MSSQL.
Look-up Based Approach-Solution
“For every design problem, we should have a solution”
If we think in that way, we can have shared data store in
our architecture and we should provision all service to access this store to
get the Enum values. In this way, we can centralize the common logic, and this
will be available to all services.
Look-up Table structure
Our Look up table should be in key-value pair pattern
Conclusion
Look-up tables are read-only tables, but we can seed
additional data if needed, with new unique key. In such way we don’t have to
work on any specific service and the shared data will be propagated all over
microservices. The data which I mentioned is up to my knowledge, though there
may be better solution than that. Please share If you any feedback on my thought/solution.
Comments
Post a Comment