cwilby/acme-architecture

An example ASP Web API project developed to .NET best practices.

acme-architecture's Issues

Communication between services

Hey,

I have a question about Acme.Core layer, most specifically the Acme.Core.Service.

Based on your example and on code that I see around the internet, it's rare to see two services communicating between themselves.

Imagine you've service A and Service B, and you need to create a method on Service B that has some logic that is already implemented by a method on service A.

How do you deal with this? Do you add a reference to that service and invoke the corresponding method or do you repeat the logic on the service that you are working on?

I have the idea that each service method should map to one business use case. This means that it is not recommended to have methods calling each other, because they work independently and each one of them solves a specific use case (the method you are calling might invoke unitOfWork.Commit(), meaning your pending changes will be saved without you knowing it, or you can have your method inside a transaction and the method you're calling might take too long to run).

I'm a little bit confused about this topic because on one side I want to promote code reuse but then I start thinking about all the problems that might occur with DbContex, TransactionScopes, etc.

Support multiple DbContext

Hello again,

I was trying a different strategy with your architecture, which is separating the DbContext into multiple DbContexts (I'm trying to apply some DDD patterns).

However, I'm not having an easy time with IUnitOfWork because it is coupled with the AcmeDataContext. I was thinking about creating a IUnitOfWork where T could be a DbContext, but this means that the Core layer would need to have a reference to Entity Framework, which I was avoiding.

Do you have any ideas on how to decouple IUnitOfWork from AcmeDataContext while still being capable of using IoC to register multiple DbContexts?