Ilja Tollu (8) [Avatar] Offline
#1
Hello, all!

I've tried to figure this question out for quite some time, but at last here it is.

If I understand the purpose of domain model file structure correctly, then each service serves some particular use case, maybe parametrized on types.

But suppose that several such services use some common parts. Say, I have the following formatter which is used converts media type objects (JSON, XML, ...) to domain model objects and back:
trait Formatter[MediaType, DomainType]{
    def read(source: MediaType): Valid[DomainType]

    def write(obj: DomainType): MediaType // Or maybe Valid[MediaType] to make it compose
}


Such a formatter is definitely not a service by itself. It is rather adapter and is used in all use cases involving, for example, REST controllers. So, it is used by the services, i.e. should be part of domain model.
In general, my question is not about adapters in particular, but about such abstract common parts, which are used throughout the domain algebra.

What are good ways to bring such abstracts into the physical structure of the domain model?

Thank you!
Debasish Ghosh (111) [Avatar] Offline
#2
Keep them as traits within a common package that all services can access. It can be a package object in Scala as well. The advantage of keeping them as traits is that you can supply specialized implementation (think typeclass design pattern) for different services.

Thanks.