For my current project we have a set of Entities, Clinic, Patient, Address. we use EF Core, with GenericRepo and Service Pattern

Entities Relation

Entities Relation

As you can see above these are the relations of the entities.

• Clinic must have an Address

• Patient must have an Address

• An Address can actually live on its own (can be searched and added to a clinic for example)

Following this, I was naive and immediately created the following Services:

The First Issue

We realized that the ClinicService will have to somehow operate both on Clinic and Address. For me there are two solutions

Both have problems:

• if I include the AddressRepository then I loose the Business Logic hidden inside the AddressService

• If I include the AddressService then I loose integrity. The Service acts as a UoW so when Creating a new Address, this would be saved in the DB. Then if the ClinicService had any bug further, it would result in an orphan address being created.

Second Issue

To make things more complicated, we have of course, controllers exposing basic CRUD functions. As described above, we can create both a clinic and an address, so we must have the AddressService and ClinicService

• Should the ClinicController have access to ClinicService and AddressService ? The problem with that is still that each service is a UoW so we would still have potential orphan addresses. Also because we return those Contracts think, DummyModels we loose the EF binding if we return anything but the entity from the Service.

In Essence

How do we share business logic? I know in this case we could make a smart AddressClass that does the transformation, but imagine our BusinessLogic requires a DB lookup – Does that PostCode actually exist?

P.S Question has been posted on SO as well https://stackoverflow.com/questions/59693884/sharing-business-logic-between-different-uow-services