Core System

Key Insight

The core system is formally defined as the minimal functionality required for a system to operate, or as the 'happy path' representing the general processing flow with minimal custom processing. Its primary objective is to reduce cyclomatic complexity by offloading specialized processing into separate plug-in components, which in turn enhances extensibility, maintainability, and testability. A practical example is the Eclipse IDE, where the core system is merely a basic text editor capable of opening, changing, and saving files; its full functionality and usability are realized only through the addition of various plug-ins.

Instead of embedding extensive client-specific customization logic directly within the core system, such as a series of `if-else if` statements for different device IDs in an electronic device recycling application, the microkernel architecture dictates that the core system generically locates and invokes the corresponding device plug-ins. This is achieved by looking up the plug-in in a registry (e.g., `pluginRegistry.get(deviceID)`) and then executing its `assess()` method. The core system itself can be implemented using a layered architecture or as a modular monolith. In more advanced configurations, it can even be partitioned into separately deployed domain services, where each service acts as a core for its specific plug-in components, such as a Payment Processing domain service incorporating different payment methods like credit cards or PayPal as individual plug-ins.

Typically, the entire monolithic application, encompassing both the core system and its plug-ins, shares a single database. The core system assumes the responsibility for managing database connections and passing necessary data to plug-ins, a practice that fosters decoupling. This means that database changes should ideally only affect the core system, not the plug-in components. While plug-ins are generally not designed to connect directly to the central shared database, they can possess their own separate data stores—such as a simple database or rules engine for specific assessment rules—which can be external, embedded, or in-memory. The presentation layer of the core system can either be embedded directly or implemented as a distinct user interface, with the core system providing backend services, and a separate user interface can also adopt the microkernel architecture style.