Separation of concerns: persisting complex types

Question

I have the following module structure:

• core
• persistence
• extension

In my core module, I have an interface: Handler. This interface has multiple implementations in the core module as well as extension module. Some implementations depend on other complex types.

I would like to persist instances of Handler in a database. My persistence module has a HandlerRepository which needs to somehow save any Handler to the database and later read them back. Since these are very dynamic, I would like to save them as JSON documents. I do not want to add any serialization/deserialization logic to my core module.

Here is the repository signature:

interface HandlerRepository {
    fun findById(id: String): Handler
    fun save(id: String, handler: Handler)
}

One idea I had was to introduce HandlerSerializer<Handler> which could serialize/deserialize a specific type of a Handler. I could do something like the following:

interface HandlerSerializer<T: Handler> {
    fun serialize(handler: T): String
    fun deserialize(json: String): T
}

object HandlerSerializerRegistry {
    private val serializers = mutableMapOf<KClass<*>, HandlerSerializer<*>>()

    fun <T : Handler> registerSerializer(type: KClass<T>, serializer: HandlerSerializer<T>) {
        serializers[type] = serializer
    }

    fun <T : Handler> getSerializer(type: KClass<T>): HandlerSerializer<T>? {
        return serializers[type] as? HandlerSerializer<T>
    }
}

Then, to save a Handler, I would get the HandlerSerializer for that specific Handler from the HandlerSerializerRegistry and serialize it.

This seems like an acceptable solution and separation of concerns to me. However, I am having issues figuring out where to put HandlerSerializer implementations and tests for them? Putting these in core and extension does not seem correct to me and I cannot add them in persistence since that module does not know which Handler implementations exist.

Any advice? Is my design wrong? Am I missing something obvious?

Answer 1

If you need some serialization code which is specific for certain Handler implementations, my first choice would be to make it part of the type itself (i.e. derive the handler directly from interface HandlerSerialize) and hence put it into the same module where the specific Handler lives (core or extension). I would not discard that solution so quickly just because of a superstitious feeling of being "not correct" - in case the serialization code requires access to private members, it may be simply the most straightforward solution.

If the serialization code is separable from the specific Handler type (which means it does not need access to non-public members), and core and extension become so large maintenance gets confusing, you may introduce two new modules coreSerializers and extensionSerializers and put the code there. As always, introducing more structure comes for the price for increased management efforts, so I would recommend against starting with this design - better refactor to this structure when the code base grows in this area.

Generic serialization code like HandlerSerializer<T: Handler>, however, can be placed in a neutral location, since it does not create a dependency on specific handler implementation. It could by either placed in persistence or in some new module serialization, whatever you prefer.