DDD is the blueprint and can be implemented by microservices. In other words, once DDD is done, we can implement it using microservices. This is just like how, in our application, we can easily implement Order services, Inventory services, Tracking services, and so on.
Once you have dealt with the transition process to your satisfaction, a simple exercise should be performed. This will help you verify that the size of the microservice is small enough. Every system is unique and has its own complexity level. Considering these levels of your domain, you need to have a baseline for the maximum number of domain objects that can talk to each other. If any service fails this evaluation criterion, then you have a possible candidate to evaluate your transition once again. However, don't get into this exercise with a specific number in mind; you can always go easy. As long as you have followed all the steps correctly, the system should be fine for you.
If you feel that this baseline process is difficult for you to achieve, you can take another route. Go through all the interfaces and classes in each microservice. Considering all the steps we have followed, and the industry standard coding guidelines, anybody new to the system should be able to make sense of its purpose.
You can also perform another simple test to check whether the correct vertical isolation of the services was achieved. You can deploy each one of them and make them live with the rest of the services, which are still unavailable. If your service goes live and continues listening for incoming requests, you can pat yourself on the back.
There are many benefits that you can derive from the isolated deployment capability. The capability to just deploy them independently allows the host in them to enter its own independent processes. It allows you to harness the power of the cloud and other hybrid models of hosting that you can think of. You are free to independently pick different technologies for each one of them as well.