Microservice Migration - yibinericxia/documents GitHub Wiki

Schedule consideration

The time factor plays an important role in project delivery. If the schedule is tight, you may have to consider to share the common database as it is instead of having your own, so that you can move your data access layer (jpa/jdbc) from the monolith to the microservice without much efforts.

Boundary consideration

How to divide the domains into different service components are critical.

Microservice Design consideration

For the monolith code with the MVC design pattern, it will be easier to migrate into 3 layer microservice architecture consisting of the following:

• presentation: API & Controller
• service: business logic processing
• data access: repository/DAO

DTOs are for presentation to retrieve resources aggregated from the related services to reduce HTTP requests or to massage into different forms to meet clients' needs. Services will use data access layer to conduct operations on Entity objects which maps database table contents.

Database consideration

Ideally each microservice should have its own database so that its database schema or schemas out of the microservice can be changed independently. If the databasee is shared with other microservices or applicatons, it is recommended to use low level database operation, such as JDBC instead of JPA for relational database, so each database entity can be operated directly. Of course to use JDBC may involve more coding and potential issues in database migration due to its dependency on thee database vendor. See more details in Database Migration

If the binary content is stored in database, it may be a good time to move it to the cloud blobs storage and store its URI in database.

Deployment consideration

Good for both production deployment and local debugging.