Where to put general purpose serialization class in domain driven design?

Question

I am trying to follow the DDD principles in my design, and I'm trying to keep my domain entities clean. I have to create serializer class (which uses json.net) and I don't know where to put it. I considered the following options:

Creating a utility project would be easy, but it would just drive a spike through the onion.
It is a bit similar to the Repositories because it contains actual implementation and has a dependecy (like the repo uses EF), but it does not store the object, just converts it.
It is not a domain service, as it does not contain business logic
Putting it into outer layer like Application or UI would not make too much sense to me.

Here is my project structure:

Web

Application

DomainServices

Repositories

DomainModel

It's part of the infrastructure (repositories & other external services if you need them) — MikeSW
I'm nut sure, because the infrastructure is the topmost layer(or ring), and layers should only use the ones that are below them. Maybe if I create an interface and place it in the application core somewhere, and put the implementation in the infrastructure that could work. What do you think? — Herr Kater

L-Four L-Four · Accepted Answer · 2016-04-11T07:15:14

If you use onion architecture it means that you work with interfaces to avoid hard dependencies from your middle rings to the outer infrastructure; and the actual implementations are injected at run time.

Serializing functionality is an infrastructural concern, so the logic belongs there, but from your domain layer you program against its interfaces, and so you don't have a dependency to the actual serialization implementation, which is the whole idea of onion architecture: if later the serialization method changes, it only impacts infrastructure layer.

Where to put general purpose serialization class in domain driven design?

2 Answers