sources

Domain-driven design (DDD) is a software development philosophy centered around the domain, or sphere of knowledge, of those that use it. The approach enables the development of software that is focused on the complex requirements of those that need it and doesn’t waste effort on anything unneeded. The clients of domain-driven design are often enterprise-level businesses.

Microservices are not free; the trade-off for having flexibility and scalability is having to manage a complicated system.

• How do we start and stop a fleet of services?

• How do we aggregate logs/metrics/service level agreements (SLAs) across microservices?

• How do we discover services in an elastic environment where they can be coming, going, moving, etc.?

• How do we do load balancing?

• How do we learn about the health of our cluster or individual services?

• How do we restart services that have failed?

• How do we do fine-grained API routing?

• How do we secure our services?

• How do we throttle or disconnect parts of a cluster if it starts to crash or act unexpectedly?

• How do we deploy multiple versions of a service and route to them appropriately?

• How do we make configuration changes across a large fleet of services?

• How do we make changes to our application code and configuration in a safe, auditable, repeatable manner?

As an autonomous service team, you cannot place obligations on other teams and services because you do not own them; they're autonomous by definition. All you can do is choose whether or not to accept their promises of functionality or behavior.