Design Patterns implementation in Domain Driven Design

Question

I'm building an application using DDD and Hexagonal Architecture with Typescript as a primary language.

Recently I had a problem that needed the observer design pattern implementation to be solved.

It is now solve and I want to refactor it, the first thing that comes to mind is to move it since I have put it in the Domain layer because there are 2 interfaces and 2 implementations of the interface that do not use any 3rd party libraries.

Even though they are not using 3rd party and somehow are not "polluted" by an external system, it feels bad to place them in the domain layer because it is not a domain matter.

I have thought to put them altogether in the Application layer just above Domain but behind Infrastructure. I just don't want to guess this kind of things the first time I implement them and would like to know where they are common to place in.

Answer 1

Indeed some code doesn't seem to fit nicely in the standardized domain/infrastructure/application layers. Generally speaking code like String utilities eg Strings class, list utilities eg Lists class and so on which kinda extend the standard library won't find a natural home in the architecture.

If you have a monolith with multiple bounded contexts it could make sense to create a common or shared module at the root and place those there. This is what Vaughn Vernon did in the IDDD samples . That would be regarded as a SharedKernel in DDD terminology. Note that I'm 100% sure whether the SharedKernel is the entire common module, or only the shared parts of the domain model. As "shared kernel" describes a kind of relationship between bounded contexts then I'd say it's the whole thing, but some don't seem to agree. Eg

I want to make clear that this is NOT the same thing as the Shared Kernel, which I covered in the previous blog entry on Domain-Driven Design. The difference is that the Shared Kernel is a common library for the Domain layer, which contains common base classes, domain entities, value objects, etc. which are shared across bounded contexts. https://blog.jacobsdata.com/2020/02/19/a-brief-intro-to-clean-architecture-clean-ddd-and-cqrs

If you only have a single BC you could still extract it the same way or you could have another layer within the BC (eg util , seedwork ) which is not really part of the architecture.

Note that it's important not to fall prey to trying to develop a reusable library/framework that will be used across many projects as it will make it much more harder to change & evolve. Rather than sharing, sometimes copying & adapting makes more sense. This very concept is generally called a SeedWork .