model a single sub-domain at a time, focus on autonomous pieces of the domain, resulting software is closer to business understanding, often no side effects
It describes independent problem areas as Bounded Contexts (each Bounded Context correlates to a microservice)
avoid chatty communications between microservices
you should create a boundary around things that need cohesion. It is similar to the Inappropriate Intimacy 20 code smell when implementing classes. If two microservices need to collaborate a lot with each other, they should probably be the same microservice.
Persistence Ignorance (PI): classes modeling the business domain should not be impacted by how they might be persisted. Thus, their design should reflect as closely as possible the ideal design needed to solve the business problem at hand, and should not be tainted by concerns related to how the objects’ state is saved and later retrieved. Some common violations include domain objects that must inherit from a particular base class, or which must expose certain properties. Sometimes, the persistence knowledge takes the form of attributes that must be applied to the class, or support for only certain types of collections or property visibility levels. There are degrees of persistence ignorance, with the highest degree being described as Plain Old CLR Objects (POCOs) in .NET, and Plain Old Java Objects (POJOs) in the Java world.
series by Jimmy Bogards