by Yes. Here we are. In the part 1, we have discussed microservices, its advantages, and disadvantages. Also, we have compared it with monolithic architecture. Aaand, we have decided to build an application with microservice architecture, right?. Well, if everyone remembered all of these, let’s start to our application.
Before immediately start coding a project, we have to be careful, think, analyze and draw the application frame, borders, decide its features, its business logic. Without doing these, we may be stuck even at the beginning. Our application will not be complex and we will not spend a lot of time on this however these are very nice practices to prepare ourselves to real-world complex projects. Also my coworker’s pc wallpaper says that think twice, code once.
Our application will be a simple version of Spotify. Let’s think about Spotify. What can we do with it?
- We are able to log into our account.
- We are able to change and/or update our profile settings & info.
- We are able to search for other users, lists, artists, albums, songs, etc.
- We are able to CRUD (create, read, update, delete) our lists.
- We are able to like a song, follow others and lists.
- We are able to upgrade our account to a premium.
- Of course, we are able to play, pause, stop, shuffle songs.
When we think about all of these features, we should be careful while building our microservices structure. Our microservices shouldn’t be very dependent on each other (low coupling). At the same time, they have to be work together to compose an application.
I think we may write down some higher-order classes over the features and can bring similar features together under these classes. Our higher-order classes may be like following.
- User-specific features
- Content-specific features
- Player-specific features
- Subscription
Also, the user-specific features can be divided into user itself and user activities. I think we are good, right? Let’s classify the features under these.
- User-specific features
- User
- Users must be able to log into their own accounts.
- Users must be able to change and/or update their own account settings & info.
- Users must be able to search for other users and/or artists.
- Users must be able to follow other users and/or artists.
- Users must be able to block other users and/or artists.
- User activities
- Users must be able to CRUD their own song lists.
- Users must be able to search for other users’ lists.
- Users must be able to follow other users’ lists.
- Users must be able to like songs.
- User
- Content-specific features
- The system must be able to keep and stream songs.
- The system must be able to keep and stream albums.
- The system must be able to allow searching for songs and albums.
- The system must be able to allow CRUD operations on songs and albums.
- Player-specific features
- The system must be able to allow play/pause/stop/shuffle songs and albums.
- Subscription
- Users must be able to upgrade or downgrade his/her subscription.
Wow. A lot of things to do. Now, when we look at this list, we may decide our microservices. We tried to keep the low coupling rule as much as possible. Let’s decide.
- User-specific – user microservice
- User-specific – user activities microservice
- Content microservice
- Player microservice
- Subscription microservice
Here is our microservices diagram and their dependencies.
We may separate login and may build it as OAuth2 microservice but for now its enough. We examine it in another article. As in the diagram, the other microservices make a request to the user microservice in order to validate the current user session. The player microservice makes a request to user activities microservice in order to get the user’s song lists info. And player microservice makes a request to content microservice in order to stream songs and albums.
Our microservices deserve better names. Let’s code our application in the next article. See you soon. Take care of yourself.
