Applications

Of all the aspects of a software system, maintenance is the most costly. The never-ending parade of new features and the inevitable trail of defects and corrections consume vast amounts of human resources. The primary cost of maintenance is in spelunking and risk. Spelunking is the cost of digging through the existing software, trying to determine the best place and the best strategy to add a new feature or to repair a defect. While making such changes, the likelihood of creating inadvertent defects is always there, adding to the cost of risk. A carefully thought-through architecture vastly mitigates these costs. By separating the system into components, and isolating those components through stable interfaces, it is possible to illuminate the pathways for future features and greatly reduce the risk of inadvertent breakage.

— Robert C. Martin

Using any shared library or framework is a kind of maintenance. If we can't understand and configure it, we throw it away. So to speed up the understanding of “how it works”, the macha project has a subproject called apps.

In the Machanism ecosystem, Application Projects play as the adaptation and customization layer, acting as the bridge between Core Projects and MachaOn Projects.

Unlike traditional application layers that connect Core logic to the User Interface (UI), Machanism’s Applications serve a different purpose:
They are the customization and adaptation layer for Core shared components, ensuring they align with the specific needs and deployment requirements of the MachaOn layer.

Project structure

Project Structure

What is an Application Project?

An Application Project in Machanism is a module designed to tailor Core shared libraries for specific workflows, use cases, or infrastructure needs.
It takes the generic, reusable Core components and adapts them, enabling them to be seamlessly integrated and deployed through a MachaOn Project.

Think of it as an intelligent intermediary that configures and refines Core functionality for deployment purposes while keeping the system modular and flexible.

Key Responsibilities of an Application Project

  1. Customizing Core Logic

    • Application Projects adapt general-purpose Core components (such as entities, use case interactors, and adapters) to fit specific deployment or business needs.
    • For example, they might define region-specific rules, add additional business constraints, or configure Core functionality for a particular infrastructure.

  2. Preparing for Deployment

    • Application modules ensure that the Core functionality is packaged and ready to integrate with MachaOn layers seamlessly.
    • They bridge any gaps between generic logic in Core components and the specific infrastructure requirements handled by the MachaOn layer.

  3. Flexible Adaptation Across Systems

    • Core Projects remain reusable across multiple contexts, but Application Projects enable the flexibility to adapt the shared Core logic for different workflows or deployment styles.

Why Applications Matter

In Machanism, the idea of modularity and separation of concerns is key. Without the Application layer, you lose the ability to cleanly separate Core business logic from the infrastructure-focused logic of MachaOn.

This separation ensures:

  • The Core remains generic and reusable without introducing domain-specific or deployment-specific clutter.
  • The MachaOn layer focuses on orchestration and deployment of pre-configured components without needing to handle raw Core logic directly.

How Application Projects Work

  1. Start with Core:

    Applications rely on Core shared libraries, inheriting generic entities, use cases, and adapters as the foundation.

  2. Tailor Behavior:

    Applications take these generic Core components and customize them to meet the specific requirements of the target system or deployment environment.

    • For example, an Application module might adapt a Product entity to account for regional tax rules in an e-commerce solution.

  3. Prepare for MachaOn Projects:

    Once the Core components have been adapted, they are passed to the MachaOn Project, which orchestrates and deploys the full solution, including the customized components.

Core vs. Application: The Separation of Concerns

It’s important to understand where Core ends and Application begins:

  • Core Projects: Provide shared, reusable, and generic business logic, entities, and workflows. Core ensures consistency across the Machanism ecosystem.
  • Application Projects: Adapt and customize this logic for practical deployment. They are specific to the needs of a solution and help tailor the Core components without breaking their modular and reusable design.

Applications and MachaOn: The Perfect Bridge

An Application Project’s primary role is to bridge Core Projects with MachaOn Projects, translating generic functionality into deployment-ready components.

Where MachaOn orchestrates the full application deployment, it relies on Applications to prepare and configure functional bricks from the Core layer. Together, these layers complete the journey from generic reusability to operational deployment.

Key Benefits of Application Projects

  • Alignment with Deployment Requirements: Applications ensure that Core components align with the specific goals of the MachaOn deployment.
  • Adaptation Without Breaking Modularity: Core projects stay generic and reusable, while Applications introduce slight, deployment-specific customizations.
  • Maintainability and Decoupling: Applications handle business-specific logic separately from both the Core and MachaOn layers, improving flexibility and maintainability.

The Applications layer is integral to Machanism’s modular philosophy. With Applications, Core components are not just reusable—they are adaptable for any deployment scenario. By creating a clear bridge between Core and MachaOn, Applications ensure a smooth and scalable development lifecycle.