Follow domain-driven design

Focus on the responsibility that the microservice is trying to meet. The scope of the service is more important than the lines of code used to build it. Teams would usually sit together and build an understanding of the domain from the domain experts. Once the domain is understood, then it is modeled as domain objects, which can be further grouped as sub-domains. In a monolith, the entire domain model is within a single application, but the microservice architecture would lead your domains to be used within different business contexts.

Bounded Contexts is a term used in DDD, which maps the domain entities within the context of its usage. A payment microservice might require a domain entity such as User, to be used for billing purposes, and thus the User entity may need to have payment details associated with it. But if the same domain entity is used in a notification service, then the payment information is an additional detail, which shouldn't get leaked into this service.

The idea of a bounded context is further explained in the section on Single Responsibility.