Answers: <p>From my point of view, you can design microservices just like classes in an application. That is, you are looking for maximum <em>cohesion</em> within a service. In other words, all stuff inside one microservice should work together to achieve exactly one well-defined <em>responsibility</em>, and no other microservice should have any content for the same responsibility.</p>
  
  <p>Furthermore, you want to minimize coupling. That is, mainly, that each microservice should have a very well defined interface, and should be easily replacable in the grand scheme of things. This also means making use of concepts like dependency injection and such.</p>
  
  <p>So as long as you have these two aspects under control - cohesion and coupling - you are fine. The exact separation of concerns (more coarse or more fine-grained) is not <em>that</em> important and will likely differ between different applications.</p>
  
  <p>There are obvious concerns here - for example, it would not make sense to put "Logging" and "GUI" in the same component (ask yourself questions like this: "Would anything else than a GUI use the Logging?" or "Does GUI need to know how Logging is implemented?" or "Does the GUI need to be implemented by the same team that does Logging?" and so on). Another frequent example would be handling of data imports - does that belong into the GUI service just because users usually upload their Excel files through a GUI? Obviously not - you may wish to upload Excel via a REST API or by pulling them from another server in a batch job, etc.</p>
  
  <p>So, in your example, you best sit down and define the responsibilities for every component. Make sure there are as little overlaps as possible. This will usually lead to merging of components you thought to be different; or splitting up of components which turn out to have a well-defined border.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-09-19T06:54:25.060Z
Answers: Thanks for the clarification. As `post` and `reply` is in the same category and can be merged together to reduce complexity of checking different post stats, they are merged into one module. As `user's private messages` are something totally different I designed a new module for private messages. tnx @AnoE +1
Answers: Alireza
Answers: CC BY-SA 3.0
Answers: 2017-09-18T19:08:34.190Z
Answers: 2017-09-18T20:07:38.867Z
Answers: 2017-09-18T20:07:38.867Z
Answers: AnoE
Body: <p>I have designed different part of social networking system using micro service and I have reached to the message part of the system. Messages can be private messages (maybe a separate module), the posts on the wall for each user which can be images, text, video (again maybe another module) and reply messages which is again can be a different module.</p>
  
  <p>Now my problem here is that should I design separate modules (service) for each kind of message. Should I consider load of messages as part of this concept of separating modules?</p>
  
  <p>From one view they are all messages that users use to interact with other users in the system.</p>
  
  <p>How should I design micro service for the message part of this social network?</p>
  
  <hr>
  
  <p><strong>EDIT-1:</strong>
  Micro-service modules of my project for now:</p>
  
  <ul>
  <li>user</li>
  <li>authenticator</li>
  <li>notifications (email, push, etc)</li>
  </ul>
  
  <p>Now my social network project has 3 parts for messages:</p>
  
  <ul>
  <li>users' posts</li>
  <li>users' private messages</li>
  <li>users' replies to other messages</li>
  </ul>
  
  <p>These 3 categories can be 1 module that can manage all these logics. Or 3 different modules <code>user posts</code>, <code>user private messages</code>, <code>user replies</code>. </p>
  
  <p>The question is how should I separate them? <strong>One of</strong> my concerns is that each category would get more logic and it will lead to a bloated module.</p>
  
  <p><strong>My Final Question:</strong> Is it just the role of micro service that separate a module from another or should I take complexity of module into account for the separation?</p>
  
  <p><strong>NB:</strong> By messaging I don't mean micro-service module's inter communication, but user's messages in the ecosystem.</p>
  
Comments: CC BY-SA 3.0
Comments: 2017-09-15T08:30:49.323Z
Comments: Could you add a table of the microservices and their responsibilities that you have created? With the messaging part you mean the communication between the microservices?
Comments: 030
Comments: CC BY-SA 3.0
Comments: 2017-09-15T08:40:22.477Z
Comments: @030 Could you take a look at the `EDIT-1` part of the question? By message I mean user's posts not micro-service communication.
Comments: Alireza
Tags: <microservices><architecture>
Title: How should I separate micro service modules for the message part(posts, reply, private) of a social network?
UserDisplayName: Alireza
ThreadText: # How should I separate micro service modules for the message part(posts, reply, private) of a social network?
  
  (Asked by: username_0 on 2017-09-15)
  
  I have designed different part of social networking system using micro service and I have reached to the message part of the system. Messages can be private messages (maybe a separate module), the posts on the wall for each user which can be images, text, video (again maybe another module) and reply messages which is again can be a different module.
  
  Now my problem here is that should I design separate modules (service) for each kind of message. Should I consider load of messages as part of this concept of separating modules?
  
  From one view they are all messages that users use to interact with other users in the system.
  
  How should I design micro service for the message part of this social network?
  
  ---
  
  **EDIT-1:**
  Micro-service modules of my project for now:
  
  * user
  * authenticator
  * notifications (email, push, etc)
  
  Now my social network project has 3 parts for messages:
  
  * users' posts
  * users' private messages
  * users' replies to other messages
  
  These 3 categories can be 1 module that can manage all these logics. Or 3 different modules `user posts`, `user private messages`, `user replies`.
  
  The question is how should I separate them? **One of** my concerns is that each category would get more logic and it will lead to a bloated module.
  
  **My Final Question:** Is it just the role of micro service that separate a module from another or should I take complexity of module into account for the separation?
  
  **NB:** By messaging I don't mean micro-service module's inter communication, but user's messages in the ecosystem.
  
  **Tags:** microservices, architecture
  
  > **Comments:**
  > **username_1**: Could you add a table of the microservices and their responsibilities that you have created? With the messaging part you mean the communication between the microservices?  
  > **username_0**: @username_1 Could you take a look at the `EDIT-1` part of the question? By message I mean user's posts not micro-service communication.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2017-09-18. Score: 1 | Accepted answer
  
  From my point of view, you can design microservices just like classes in an application. That is, you are looking for maximum *cohesion* within a service. In other words, all stuff inside one microservice should work together to achieve exactly one well-defined *responsibility*, and no other microservice should have any content for the same responsibility.
  
  Furthermore, you want to minimize coupling. That is, mainly, that each microservice should have a very well defined interface, and should be easily replacable in the grand scheme of things. This also means making use of concepts like dependency injection and such.
  
  So as long as you have these two aspects under control - cohesion and coupling - you are fine. The exact separation of concerns (more coarse or more fine-grained) is not *that* important and will likely differ between different applications.
  
  There are obvious concerns here - for example, it would not make sense to put "Logging" and "GUI" in the same component (ask yourself questions like this: "Would anything else than a GUI use the Logging?" or "Does GUI need to know how Logging is implemented?" or "Does the GUI need to be implemented by the same team that does Logging?" and so on). Another frequent example would be handling of data imports - does that belong into the GUI service just because users usually upload their Excel files through a GUI? Obviously not - you may wish to upload Excel via a REST API or by pulling them from another server in a batch job, etc.
  
  So, in your example, you best sit down and define the responsibilities for every component. Make sure there are as little overlaps as possible. This will usually lead to merging of components you thought to be different; or splitting up of components which turn out to have a well-defined border.
  
  > **Comments:**
  > **username_0**: Thanks for the clarification. As `post` and `reply` is in the same category and can be merged together to reduce complexity of checking different post stats, they are merged into one module. As `user's private messages` are something totally different I designed a new module for private messages. tnx @username_2 +1  
  
  ---
  
  