I would strongly advice against using DTC in such a heterogeneous environment. There are multiple risks involved. Only one of them is limiting your future choices: what if you have to use a file system that cannot enlist it a transaction (say, network fileshare)? Or cloud frontend? Or some 3rd party service?
Also DTC couples parts of your system together very badly. All sorts of coupling are involved: spatial, temporal, even platform (because everyone must know how to enlist in a specific DTC).
Despite performance (which is thousands of times worst with DTC than without) aspects, DTC works great until it doesn't. You should be prepared to "transaction is in doubt" situations and all sorts of troubleshooting if you use DTC. And it should be a part of your design.
There are cases when DTC is needed for some rare specific cases in systems, but if you find yourself in a situation when you look at transactions and DTC as at a holy golden hammer (we just start transaction, and if something fails we "just" rollback everything) I recommend you to stop right now. You will save tons of time, bugs, nerves, money, resources if you stop here.
I believe it would be more logical and much better to make a proper design that would not require DTC. Remember: business does not rollback. We do, programmers. When money are being transferred from one account to another (possible in different banks), there is no DTC involved, it would be crazy. They do not rollback, they compensate. There are patterns and ways to do it properly, we cannot just wrap the whole world in a transaction.
So design your systems against independent contexts that can operate autonomously and communicate to each other naturally and you will find yourself in a much better world :)