3

I'm currently in the process of migrating a legacy application to a domain driven design model and I came across this issue: The application is about managing a large amount of contacts in real time including checking for duplicates. Whenever someone saves a new contact, it has to pass a duplicate check with a 3rd party software (it's basically a similarity search software). If it passes the check, the contact will be created in SQL and a small subset of the contact (some core fields which are relevant for duplicate checking) has to be stored in the database of the 3rd party software. So the entity "contact" lives in two (synchronized) storage systems, but one system only has a small subset of fields whereas SQL has 50+ fields for the contact.

Now I was thinking if it would be OK to create two types for "contact" (Contact and ContactShort). As a result I'd also have to create two repositories for those entities and use those repositories in a domain service which is ultimately used to perform those operations where I need the duplicate checking software (like the Save/Insert methods).

Is there a good rule of thumb of how to approach such a scenario?

EDIT: I still haven't found a definitive solution but thought a bit more about it: Maybe it was wrong to separate the duplicate checking storage system from the SQL DB in this case. Actually, I think it is wrong to expose the methods of the 3rd party software. It is pure infrastructure. Since a save operation must never be performed without the duplicate check, I think the calls to the 3rd party software should be internal to the SQLRepository. It must never leave the infrastructure layer since it can never return a valid entity of a contact. What do you think?

hoetz
  • 2,368
  • 4
  • 26
  • 58

1 Answers1

1

To me your suggested solution sounds good. At the lower level (data access layer) you should have two independent objects that wrap access to two different databases (two repositories, as you require different connection strings. This can be 2 instances of the same XXXRepository if you use the same database engine, or it can be different repositories XXXRepository and YYYRepository to access 2 different database engines).

On the upper level (Domain Layer and GUI), however, you shouldn't be bothered how and where these data go. As you said, you have a service that separates the pluming so that the application domain and upper layers (like GUI) won't see what's happening below (in data access layer).

oleksii
  • 35,458
  • 16
  • 93
  • 163
  • What do you mean with "Lower level" and "Upper level"? Is lower level a concrete implementation of a repository interface defined in the domain layer? – hoetz Jun 13 '11 at 05:34
  • @Malkier sorry for that, I expanded my answer. Under Lower level I meant data access pluming, and Upper level is anything above that - business logic and GUI. Lower level will have two repositories, but you will access them via the Service. Only the service will know how to manipulate data using 2 repositories, so you hide your repositories from the domain layer. This is how I see it, of coz it be wrong. – oleksii Jun 13 '11 at 07:45
  • @Malkier there is a rational sense in that. Keep in mind you will use the same repository in the whole system. So anyone who has access to the infrastructure will be able to call the method with additional checks to external db. – oleksii Jun 19 '11 at 21:07