The Author Online Book Forums are Moving

The Author Online Book Forums will soon redirect to Manning's liveBook and liveVideo. All book forum content will migrate to liveBook's discussion forum and all video forum content will migrate to liveVideo. Log in to liveBook or liveVideo with your Manning credentials to join the discussion!

Thank you for your engagement in the AoF over the years! We look forward to offering you a more enhanced forum experience.

Ilja Tollu (12) [Avatar] Offline
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 (116) [Avatar] Offline
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.