CODEWITHSUNDEEP
architecturedomain-driven-designdaoddd-service
user3767551
user3767551

Reputation: 69

Where to keep the common services?

In Domain Driven Approach - Where to keep the common services?

Eg., Sometimes we may need to have common functions like getcountrylist, getstatelist, getcitylist, (or some other data from MASTER tables) to show the dropdown in the different pages/modules of UI. Assume if these data are present in the database then where we need to have these functions.

  1. Can i keep these functions inside a Domain/Common/CommonServices.php (I mean inside domain layer is good?) (or)

    Can i keep these functions inside a Infra/Common/CommonServices.php (in this case i need to connect to dao layer directly from Infraservice layer which i feel is not correct?)

  2. What is the right name / suggestible name for the file which contains these common functions. (CommonServices.php (or) CommonHelper.php (or) CommonUtils.php (or) MetadataService.php (or) any of your suggestions)

Upvotes: 3

Views: 1115

Answers (2)

guillaume31
guillaume31

Reputation: 14064

The behavior has to do with data, so I would place it in a special Repository or a Read Model facade. You could go with a domain Service as well, but Service is an overloaded term and doesn't convey the data access aspect IMO.

If you adopt a CQRS approach, I'd recommend placing it in a separate Read module. Otherwise you can keep the interface in the Domain layer and the implementation in Infrastructure, as with other repos.

(edit) to make things a bit clearer, this facade could be called directly by Controllers since it is just readonly access, as opposed to manipulating aggregates which may have to go through Application layer Services controlling the applicative transaction.

Upvotes: 0

Rafał Łużyński
Rafał Łużyński

Reputation: 7312

If you really need the same data in different bounded contexts and you retrieve them with the same repository, then in DDD there is something called a SHARED KERNEL. SHARED KERNEL is a place when you put things that overlap in few bounded contexts, a quote from DDD Quick:

The purpose of the Shared Kernel is to reduce duplication, but still keep two separate
contexts. Development on a Shared Kernel needs a lot of care. Both teams may modify
the kernelcode, and they have to integrate the changes.
If the teams useseparate copies of the kernel code, they have to merge the codeas soon
as possible, at least weekly. A test suite should be inplace, so every change done to 
the kernel to be tested right away. Any change of the kernel should be communicated
to another team, and the teams should be informed, making them aware of the new
functionality.

Anyway if your SHARED KERNEL is growing too large then it might be problem with your modeling. Try to keep SHARED KERNEL as small as possible.

Upvotes: 4

Related Questions