Hi Farhad,

Thanks for your response. That's an interesting question you're asking here... And I'm afraid the answer is: It depends... As always...

This could be a valid answer: The scenario you're describing means you will have two deployment manifests. The two API's will have the same business rules. How will you make sure these are not getting out of sync? Perhaps this a reason to say: Let's put everthing into one big repository.

But maybe you have multiple teams working on the project. One team is working on Api1, the other on Api2. And they both need to work on the domain. Having everything in the same repository will probably get messy. Now it might be a good idea to put the different API's in seperate repositories, put the domain in a seperate repository too and build it into a nuget package. Use dependabot to automatically push the newest version to all api's and cover functional risks by using behavioral, holistic, automated tests that run in the deployment pipeline..

Or maybe.. You should apply the BFF approach? (Tried to explain the concept and list relevent content about it here: https://abstarreveld.medium.com/what-is-a-bff-and-how-to-build-one-e2a2b78cfc43) Expose the domain via its own, dedicated, general-purpose API. Create two API's that use the domain API to expose the functionality that's needed further down the chain.

Anyways.. I think the correct answer depends on a couple of things:

* Who's working on the project?

* Do they communicate well?

* Are there any risks that need to be mitigated? (Business rules getting out of sync, breaking changes, hidden dependencies to other business rules, etc,)

* What's the desired time to market?

* And so forth

Hope this helps?

Cheers