Các microservice trong kiến trúc microservices cần được xác định sao cho các microservice này phải tách rời nhau nhằm đảm bảo khi thay đổi bất cứ microservice nào cũng không làm ảnh hưởng đến các microservice khác nhưng đồng thời cũng cần đảm bảo phải có sự kết nối cao giữa các microservice trong hệ thống. Để làm được điều đó khi xây dựng các microservice trong hệ thống ta nên làm một cách riêng rẽ, mỗi microservice nên có một cơ sở dữ liệu riêng để đảm bảo tính độc lập trong kiến trúc microservices. Tuy nhiên việc thiết kế cơ sở dữ liệu riêng, độc lập cho mỗi microservice có thể khiến hệ thống xây dựng trên kiến trúc microservices bị dư thừa dữ liệu, để tránh việc dư thừa dữ liệu trong kiến trúc microservices thì cách tốt nhất đó là thiết cơ sở dữ liệu trong mỗi microservice phải ít ràng buộc, không có khóa ngoài.
Việc xác định các microservice phải đảm bảo sao cho khi ta muốn thay đổi một hành vi hoặc một chức năng nào đó thì chúng ta chỉ cần thay đổi ở một microservice. Để làm được điều này, chúng ta nên nhóm các hành vi có liên quan đến nhau lại trong cùng một microservice nhưng việc nhóm các hành vi này vẫn phải đảm bảo kết nối lỏng lẻo cho các microservice trong hệ thống. Trong cuốn Domain-Driven Design, Eric Evans đã đưa ra khái niệm về Bounded Context để có thể khoanh vùng được các chức năng trên miền (DDD – Domain- Driven Design). Nó rất hữu ích khi ta áp dụng để xác định các microservice
trong kiến trúc microservices. Theo Eric Evans thì Bounded Context là một mẫu thiết kế trung tâm của thiết kế hướng miền nhằm khoanh vùng các hành vi có mối quan hệ với nhau và cùng thực hiện một chức năng lại với nhau. Bounded Context giúp các nhà xây dựng phần mềm chia nhỏ các hệ thống lớn và giúp các thành phần sau khi chia nhỏ được độc lập với nhau (10). Chúng ta có thể sử dụng ưu điểm này của Bounded Context để xác định các microservice trong kiến trúc microservices.
Dựa trên các chức năng và các yêu cầu của SOML mà ta đã xác định ở phần 2.1.2, ta có thể xác định SOML sẽ có 4 vùng Bounded Context chính là: vùng chứa các hành vi liên quan đến người dùng (Users Context), vùng chứa các hành vi liên quan đến các câu chuyện (Stories Context), vùng chứa các hành vi liên quan đến các bức ảnh (Photos Context) và vùng chứa các hành vi liên quan đến các bình luận (Comments Context) (Hình 2.7)
Dựa trên các phân vùng trong SOML như vậy, ta có thể xác định ứng dụng SOML có bốn microservice:
Users service thực hiện chức năng quản lý người dùng
Stories service thực hiện chức năng quản lý Story
Photos service thực hiện chức năng quản lý Photo
Comments services thực hiện các chức năng quản lý Comment