David, that is a great question!

Our team does it by focusing on simplicity—if something is still complicated we haven’t finished designing it. We are obsessed with eliminating anything that does not directly contribute to solving the problem. That is the hardest part.

Our services are discoverable, independently deployable, and dynamically bindable. If you drop one into the class path of a service node it is instantiated and can be addressed by its name and version.

Our services are reactive message processors and have no instance variables. All they do is process synchronous, asynchronous, and event messages.

Those messages implement strict REST principles and all services implement the same Java interface. The actual context data itself is the only difference.

Each service implements a DDD bounded-context, aggregate, or entity.

We use a single service class per persistent entity.

On startup, our service nodes map and instantiate all the services in their class path. They also broadcast to all other networked service nodes — with which they share their service maps—forming a federated whole.

A message to any service will be delivered to the target service and version anywhere within that federated set of service nodes.

That leaves doing a good job using DDD to model the application as the primary task in architecting and designing the application.

Obviously, the creation of the service nodes was a long hard task, but it dramatically simplifies the application side of the problem.

https://medium.com/nerd-for-tech/designing-a-rest-api-3a070398750f