The beauty of Microkernel architecture pattern.

I wasn’t at work for couple of days (that flu … ). When I came back, one of the development team leader ask to consult me about the right pattern that matches his task. The guy is responsible for a module that responsible for getting request from inner system modules for outer system modules (actually dedicate products) and return the returned data from calling outer modules to the calling internal module. As part of it work, the module need to transform data back and forward from internal modules to outer modules.

The interesting part of his task is the demand to build his solution in such a way that new request, for new external modules, could be made without a need to change and recompile the entire solution.

As I heard him explaining about his task I already saw in my mind Microkernel. The guy solution was a mass of classes and interfaces but without any design for dynamic adding of new calls for unknown external module. I explained him about Microkernel 5 parts including the unchanged microkernel, which holds the unchanged code. Internal services that supplies internal services to kernel. External services which builds on kernel and extend it. Adapters that reduces coupling between clients and external services. Actually he got it pretty fast that microkernel fits his needs. Microkernel will hold the unchanged code that responsible for application flaw. Internal services such as formatting, transforming and loading the right external DLL by given client request. External services are the calling outer modules, which extending the kernel services for clients.

As in good old adaptive systems we add reflection to enable splitting into external metadata the mapping of client request to external module. Reflection simply prevents any changes in the system. All changes are just dealing with updating the system external metadata (XML file in our case).