1. What kind of service is good micro service?
It should have these two characteristics: loose coupling, high cohesion
Loose coupling :
If you do loose coupling between services, then modify a service you do not need to modify the service to another . The use of micro-services most important thing is the ability to modify and deploy a single independent service without the need to modify other parts of the system, it is very important.
So what is a relatively tight coupling of it? Use tightly coupled to do the integration, modification of a service between the service will cause to modify its consumers.
A loosely coupled service should know as little as possible information about those services with collaboration.
High cohesion :
We hope the relevant act together, the irrelevant behavior anywhere else .
Because if you want to change a behavior, it is best able to make changes in one place, you can then quickly released. If you also need a lot of places to make changes, then it may simultaneously publish multiple micro-services to complete this function. In this case, changes will be slow, workload and risk of deploying services will increase.
This need to find the boundary of the problem domain, thus ensuring energy-related behavior in the same place, and they will communicate with other border to try to form a loosely coupled.
2. bounded context
Eric Evans of "Domain Driven Design", mentioned this concept.
He believes that any given bounded areas includes a plurality of contexts, each context bounded model into two parts, and does not require external communication, the other part is required .
Each context has a clear interface that determines which model it will be exposed to other contexts.
2.1 Share of privacy model
For example, for MusicCorp, the finance department and the warehouse can be two separate bounded contexts. They have a clear external interface ( inventory reports, payroll, etc. ) , but also have some of the details only they know ( forklifts , calculators, etc. ) .
Because the employees of the Ministry of Finance needs to inventory information, inventory item becomes a shared model between the two contexts. But we will not put all the content items in the warehouse inventory models are exposed to.
In many cases, this situation will lead to discussion of whether to adopt REST of the. (Because this situation can be REST way.)
2.2 modules and services
In the monolithic system, once you've found within the context of bounded areas, the use of the module must be modeled simultaneously using a shared model and hidden.
These modules boundary can become an excellent micro-service candidates. In general, micro-services should be clear and consistent bounded context. Skilled, may be dispensed in a single module to use the block system of this step, the direct use of a separate service.
Summary: micro-services and border delimitation to be consistent with the context .
At the beginning of the use of micro-services when premature will become a division of micro-services system cost is very high, especially in the face of new fields. In many cases, an existing code base will be divided into micro-services, than to start from scratch to build micro-services much simpler.
3. Business functions
When you think about bounded within the context of the organization should not be considered from the perspective of shared data, but should be considered in the context of these functions can provide.
4. gradually divided context
In the beginning you will recognize some of the coarse-grained context delimited, and these bounded contexts may in turn contain nested bounded context .
In addition, organizational structures and software architecture will affect each other.
Another reason to prefer nested approach is that it can make the structure more into blocks, so as to better testing.
5. Communication about business concepts
How to communicate with a business concept between micro-services , it is a very important thing.
To follow the same means of communication within the organization, to think about the form of communication between the micro service is very useful.
In fact, forms of communication are very important throughout the organization.
6. technical boundaries
For example, a system is divided into two parts, one part facing the front end, this part does not save any state; rear end part is a simple data storage, via the RPC ( the Remote Procedure Call, to serve remote procedure call).
Basically, you can be understood as a storage layer in the code base into a stand-alone service.
We call this architecture called onion architecture, because it has many layers.
In this case, not in accordance with the vertical division of the business carried out , but the API level inside the original process is divided out.
According to art seam (refer to different technology) divided by the border service modeling is not always wrong.
However, in general, this should not be the primary way you consider.
7. Summary
In this article, you learned what is good micro-services, and how to find cohesion and low coupling to achieve high internal seams in the problem space.
Bounded context is a very important tool for finding these seams, by micro-match service and these boundaries can ensure that the final system is able to get all the benefits of micro-services provided.