A good microservice should encapsulate a bounded context. A bounded context is a concept that comes from Domain-Driven Design (or DDD). In DDD, the components of an application are organized around the various contexts or domains in which your software can be interpreted.
As software gets larger, it becomes harder and harder to describe it with a unified model. Your software might serve three different departments in your company that each have their own definition for what a product is, or it might be used by two different types of customers. Describing all of these situations in a unified model is confusing and makes communication hard.
To solve this problem, DDD says that you should divide your application up into bounded contexts, each with its own unified model. By providing a context in which to interpret the model, it is ensured that the vocabulary used will not contradict that of other components. By supplying a namespace for each component, it is free to describe its understanding of the world as it sees fit and evolve that understanding (and vocabulary) over time.
While bounded contexts are useful generally in software design, they are especially relevant for microservices. A microservice provides a natural boundary within which to encapsulate a bounded context. Organizing microservices around bounded contexts helps to keep the task of maintaining an accurate and meaningful model more intuitive. It also facilitates an evolving model by explicitly defining the boundaries within which the bounded context exists (and thus where changes can occur without affecting the system as a whole.)