CQRS

https://threedots.tech/post/basic-cqrs-in-go/
It’s highly likely you know at least one service that:

has one big, unmaintainable model that is hard to understand and change,
or where work in parallel on new features is limited,
or can’t be scaled optimally.

Unfortunately, without proper research and planning, the situation after blindly refactoring may be actually worse than before:

business logic and flow may become even harder to understand – a complex logic is often easier to understand if it’s in one place,
distributed transactions – things are sometimes together for a reason; a big transaction in one database is much faster and less complex than distributed transaction across multiple services,
adding new changes may require extra coordination, if one of the services is owned by another team.

To be totally clear – I’m not an enemy of microservices. I’m just against blindly applying microservices in a way that introduces unneeded complexity and mess instead of making our lives easier.

Another approach is using CQRS (Command Query Responsibility Segregation) with previously described Clean Architecture and DDD Lite. It can solve the mentioned problems in a much simpler way.

https://threedots.tech/post/basic-cqrs-in-go/

https://threedots.tech/post/introducing-clean-architecture/

https://threedots.tech/post/ddd-lite-in-go-introduction/

https://threedots.tech/tags/building-business-applications/

https://lailin.xyz/post/strategy.html