Skip to content

Design philosophy

Minyu is built around a recurring pattern found in most internal business systems. Regardless of industry, these systems tend to contain the same structural elements: a structured data model, rules that control correctness and access, interfaces for interacting with information, mechanisms for exchanging data with other systems, and domain‑specific processing.

In many organizations this foundation is rebuilt repeatedly. Each new system introduces its own data structures, validation logic, interfaces, and integration mechanisms. Over time this leads to duplicated infrastructure and systems that are increasingly difficult to change.

Minyu’s design philosophy is to stabilize this shared structural foundation while leaving domain‑specific processing outside the core system. The goal is to provide a predictable base for building internal systems without forcing organizations to rebuild the same infrastructure for every new application.

The structural backbone of business systems

Most internal systems can be understood through five recurring structural characteristics.

  • Structured data – entities, attributes, and relationships
  • Rules – constraints determining what is allowed, visible, or valid
  • Interaction – the ways users explore and modify information
  • Data exchange – integration with external systems
  • Processing – domain‑specific automation and computation

Minyu standardizes the first four of these elements and exposes them through a consistent model. Domain‑specific processing remains external and interacts with the system through integrations.

flowchart TB
    classDef bigText font-size:30px;
    classDef normalText font-size:22px;

    IS[Information System]:::bigText

    IS --> DM[Structured Data]:::bigText
    IS --> RL[Rules]:::bigText
    IS --> VI[Interaction]:::bigText
    IS --> IE[Data Exchange]:::bigText
    IS --> DP[Processing]:::bigText

    subgraph MINYU[" "]
        DM --> DM_M[Declarative schema Tables, relations, constraints]:::normalText
        RL --> RL_M[Central rule engine Access, validation, state]:::normalText
        VI --> VI_M[Data‑driven views Forms, lists, calendars]:::normalText
        IE --> IE_M[Model‑driven integration Imports, exports, API, events]:::normalText
    end

    DP --> DP_E[External domain‑specific systems Billing, payroll, logistics]:::normalText

    style MINYU fill:#f5f7fa,stroke:#555,stroke-width:1px
    style DP_E fill:#ffffff,stroke:#999,stroke-dasharray:4 4

Rapid change and time to market

A key design goal is to reduce the time required to evolve internal systems.

In many platforms, even small structural changes require coordinated updates across the database schema, application logic, APIs, and user interfaces.

Minyu avoids this fragmentation by making the data model the central definition of the system. When the model changes, the effects propagate automatically to:

  • forms and views
  • queries and APIs
  • relations and navigation
  • integrations and scheduling behavior

This allows organizations to adapt systems quickly without rebuilding multiple technical layers. Structural changes become configuration changes rather than development projects.

Centralized rules

Rules determine what is allowed, visible, or valid. In Minyu they are expressed declaratively and evaluated consistently across most system entry points.

Instead of embedding validation logic in custom code, constraints and permissions are defined once and enforced by a central rule engine. This ensures that behavior remains predictable regardless of whether changes originate from the user interface, APIs, or automated processes.

However, some system operations intentionally bypass write rules.

Bulk imports and certain platform‑level operations—such as GDPR cleanup procedures—operate at a structural level and therefore do not evaluate write rules. These mechanisms are designed for controlled data maintenance and administrative operations rather than normal application workflows.

Data‑driven interaction

Minyu’s interaction model is derived from the data model itself. Views are generated from structural patterns such as relations, classifications, and time.

Forms, lists, calendars, explorers, and charts are created automatically based on the schema and rules. Navigation follows relationships directly, preserving context across different views.

This keeps the interface consistent and ensures that interaction patterns evolve automatically as the model changes.

Model‑driven integration

Business systems rarely operate in isolation. Minyu provides several integration mechanisms derived directly from the model:

  • bulk import and export
  • API access to the structured schema
  • relational queries
  • event notifications

Because integrations are generated from the same structure used internally, external systems interact with the same consistent model as the user interface.

Separation of structural and domain logic

Some operations—such as billing logic, payroll calculations, or logistics planning—are highly domain‑specific and vary between organizations.

Minyu deliberately avoids embedding these processes inside the platform. Instead, it focuses on the shared structural foundation while allowing specialized systems to perform domain‑specific processing through integrations.

This separation keeps the platform stable while allowing organizations to evolve their operational logic independently.

Summary

Minyu focuses on stabilizing the structural backbone shared by most internal business systems. By centralizing the data model, rules, interaction patterns, and integrations, the platform reduces duplicated infrastructure and enables systems to evolve quickly.

Domain‑specific processing remains external, while the platform provides the consistent structure that those processes rely on.