Repository Pattern with 2 services & 2 dataccess layers - C# DDD?

Question

Can anyone help, I have 2 applications and they are nearly identical. they have a completely different presentation layer (web) and the business logic and database are nearly identical. Basically one app has some things that the other doesn't.

so i was wondering if i can do the following without breaking any rules etc

Each app has their own presentation layer.
Each app has their own service layer.
Each app has their own data access layer.
Each app shares another service layer.

Hence the shared service layer both apps can access as the business logic is identical, but they both have another service layer which has 5 or 6 methods in there which are specific to that actual app

The data access layer - I don't see anyway of sharing this as there are 2 different db's with entity framework hence its got the EDM in there so its not dynamic - and the tables differ slightly.

I could use IOC on the shared data access layer I suppose

Would anyone help or comment weather this is good practise.. What I didn't want to do is have only a separate service layer when a lot of it is shared..

Is this a good idea? Maybe i have got it wrong, is there a better way?

Answer 1

You could unify the DAL with a Repository interface. You could then implement the interface across projects. You will probably end up with a EF Repository base class as well. You could apply a similar technique to the services, leverage a common interface and then specialize the service implementations.

Answer 2

Hi thanks for the comment,

So what you mean exactly is having a respository base class that inherits from a COMMON repository interface??

And have another repository class inherit from another interface?

Sorry a little confused, can you elaborate?

Thanks

Answer 3

If the business logic is mostly identical then you should focus to this first. If you want to do DDD then you should identify your entities and (business) services first and place these in a single library.

These entities and business services should talk to your infrastructure layer (your DAL). If the infrastructure layer is very different in these two applications then try to work with interfaces. So wrap the intfrastructure layer with interfaces and only talk from the domain layer to your infrastructure layer via these interfaces.

To bind your business logic to your infrastructure's implementation you could use IoC/DI.

Answer 4

As Arjen de Blok said, your business entities should use a repository, a repository is an object with methods to query, update or insert domain entities.

The interface which describes your repository belongs to your domain layer, but the implementation belongs to the infrastructure layer (DAL).

You can share the domain and infrastructure libraries between your two projects. If these two projects should retrieves their data through a shared web service or a shared database, you just have to choose (i.e inject) the correct implementation of your repository (your domain objects know only about the interface of your repository, not about the concrete type)