Gateway use and Dtos from the other service

[mythz]

Start with a monolith, only separate them into separate Microservices when you can realize tangible benefit from doing so. Either case the Service Gateway which will allow you to “design for Microservices” whilst keeping them in the same monolith deployment unit whilst making it easy to decouple them into separate Microservices if you need to in future.

Here are a couple of my existing posts on the subject that may provide some more insight.

Microservices shared front end aka How does servicestack find services?

If your Services are split across multiple .dlls, you can just add the Assemblies in ServiceStack’s AppHost constructor, if you’re splitting your System into multiple Microservices than we recommend using the Service Gateway which allows you to make intra Service API calls with the same API irrespective of whether it’s calling an internal Service or external Service. Built on top of the Service Gateway are some Service Discovery solutions that take care of automatically discovering available ser…

Application Layout .NET-Core Frontend + Servicestack API

For simplicity I’d start with one unless you have a good reason to separate them as it adds complexity, especially if they’re sharing the same Database, from an SOA POV there really should only be a single App/Layer that manages/encapsulates a database. On the other side if both Apps are unrelated with each other it suggests that the Database should be decoupled and the Apps should be isolated. If you’re going to keep them using the same database then they should be in the same App. The ration…