CBD Enabled by DSL and Execution Platform: Implementable Component Structure

CBD Implementation Technologies

CBD is a highly powerful technological paradigm, yet the implementation side has often lacked sufficient support, leaving many aspects as little more than a “pie in the sky.” At present, there is no direct support at the programming language level, and even within the Java ecosystem, support is only partial through technologies such as JavaBeans, Enterprise JavaBeans, and Spring.

When attempting to support components in Java,

If development is programming-centric and based on POJOs, the full capabilities of components cannot be fully leveraged.
If component specifications are defined in detail, the configuration becomes complex, raising development difficulty while yielding only limited benefits.

one of these two tendencies typically emerges.

To resolve this problem, the following technologies are required.

A method for rigorously defining component specifications.
An execution platform that runs component specifications exactly as defined.

For this purpose, SimpleModeling provides the following products.

Cozy: A literate model compiler.
CNCF: An execution platform.

Analysis-level specifications are described using Cozy Modeling Language, a literate modeling DSL.

CNCF provides its execution-platform DSL as an internal DSL.

Cozy, as a literate model compiler, directly connects analysis models to implementation by automatically generating CNCF’s internal DSL from analysis specifications written in CML.

Through this mechanism, the “down” side of the analysis model up–down cycle is realized.

Component developers implement components by writing Scala logic bound to the component DSL.

Because logic is written after specifications have been solidified, AI-assisted semi-automatic generation can operate effectively. Not only the structural definitions provided by the DSL, but also the “literate” descriptions within the literate DSL, along with glossaries and related articles in the BoK, serve as powerful input information for AI.

Cloud Platform

In addition to the existing issues of conventional component technologies, handling cloud platforms has become crucial in the AI era. To fully leverage the capabilities of cloud platforms, component specifications and the execution platform must be aligned at the architectural level.

Cloud platforms have the following characteristics.

Multiple servers can be easily used simultaneously.
Serverless execution through cloud functions.
The ability to utilize large-scale memory.
Servers can be provisioned and used at the required time.

Leveraging these characteristics, the following properties must be realized.

Reactive.
Scalability.
Resiliency.
Performance.
Low cost.

Achieving highly responsive, scalable, and highly available applications at low cost is extremely challenging and requires the proper combination of multiple technologies.

One promising approach for this purpose is an application architecture centered on CQRS.

Separation of commands and queries.
Separation of read and write responsibilities.
Structural separation of state updates and state queries.

By defining these at the component specification level and having the execution platform realize them accordingly, a cloud-native architecture naturally emerges.

However, adopting CQRS as an application architecture significantly changes how applications are built. Therefore, modeling methods and DSLs suited to this new approach must be prepared. Furthermore, an execution platform capable of running applications based on this new architecture as they are is required.

Addressing these two challenges is one of the primary objectives of Cozy and CNCF.

Component Contracts

CNCF components define the following specifications using a DSL.

API
SPI
Service
Receptions
Events
Extension points
Variation points
Error model
Quality attributes

These specifications function as contracts governing execution on the platform.

Within the Cozy and CNCF ecosystem, analysis-level models function directly as components on CNCF, preventing divergence between models and implementation and enabling components to realize their inherent capabilities.

Contracts are enforced through the following mechanisms.

Structural constraints enforced by the DSL (specification violations are eliminated at generation time).
Enforcement of invocation boundaries by the execution platform.
Type-safe separation of API and SPI.
Runtime contract validation (error and observation models).

In other words, the decisive difference from conventional CBD is that contracts are enforced structurally rather than merely documented.

Advantages of Components

Based on the advantages of components listed in 📄 Component-Based Development in the Age of AI, with several additions, they are summarized below.

Reusability
Independence
Maintainability
CI/CD compatibility
Extensibility and portability
Clarity of deployment units
Testability
Visibility of execution boundaries
Clear separation of responsibilities

Cozy and CNCF provide various forms of support to ensure that the benefits of each advantage can be practically realized. Here, we focus specifically on reusability and testability.

Reusability

Through the two DSLs—an external DSL provided by Cozy and an internal DSL provided by CNCF—

Specifications are explicit
Dependencies are explicit
Boundaries are structurally defined

which enables components to be treated as reusable units.

Furthermore, CNCF provides mechanisms such as:

Docker components
Fat JAR components
Collaborator structures
Extension via SPI

Through these mechanisms, artifacts from the broader Java ecosystem outside the CNCF component ecosystem can be incorporated as CNCF components, enabling their reuse within the CNCF model.

Testability

CNCF components enable environment-independent unit testing through the following mechanisms.

Abstraction of side effects through functional programming
Abstraction of execution environments via execution contexts
Abstract interfaces defined by API/SPI
Extension and variation points
Application-level transactions through UnitOfWork
Externalization of inter-component coupling
Abstraction of external environments such as databases and networks
Abstraction of execution-environment elements such as time and randomness

With these mechanisms, components can be tested by substituting execution environments without modifying their implementations.

Overcoming the Weaknesses of Components

In 📄 Component-Based Development in the Age of AI, the following weaknesses were identified:

Difficulty of discovery
Cost of understanding specifications
Coupling cost
Design difficulty
Development cost
Loss of visibility

It was argued that these could be addressed through DSLs and AI. Overcoming these weaknesses significantly enhances the practical viability of component technology.

In addition, the provision of an execution platform by CNCF brings further improvements in the following aspects.

Improved visibility through clearly defined execution boundaries
Enhanced discoverability via component registration and discovery mechanisms
Standardized lifecycle management provided by the execution platform
Reduced coupling cost through unified invocation conventions
Leveling of design difficulty through DSL auto-generation
Reduction of development cost through templating and semi-automatic generation
Simplified failure analysis through integration of observation models
AI-assisted understanding of specifications and their differences

Most importantly, the presence of an execution platform allows components to be treated not merely as design concepts, but as concrete entities that can be registered, discovered, connected, and executed.

In conventional CBD,

Component definitions existed, but execution conventions were project-dependent
Discovery relied primarily on documentation
Coupling was left to human design decisions

This often resulted in a gap between theory and implementation.

In CNCF,

API/SPI are explicitly defined at the DSL level
The execution platform manages connections and boundaries
Deployment, verification, and observation are performed at the component unit level

As a result, the concept of a component is established as an “operational unit.”

Furthermore, when combined with AI,

The flow from specification → DSL → implementation becomes stabilized
Reduced cost of understanding existing components
Support for exploring coupling candidates
Impact analysis of specification changes

such forms of support become realistically achievable.

In other words, the weaknesses of CBD did not stem from being “conceptual” per se, but from the lack of supporting structure and execution platforms.

Cozy and CNCF serve as the foundational infrastructure that fills this gap.

Externalization of Quality Attributes

In SimpleModeling, the following quality attributes are treated as modeling targets.

Runtime quality
- Performance
- Availability
- Reliability
- Scalability
- Security
- Resilience
Operational quality
- Operability
- Observability
- Deployability
- Configurability
Design-time quality
- Maintainability
- Extensibility
- Reusability
- Testability
- Readability
- Consistency
Organizational and business quality
- Portability
- Interoperability
- Evolvability
- Economic efficiency
AI-related quality
- Model readability
- AI operability
- Context stability
- Suitability for automatic generation

In addition to traditional runtime, operational, design-time, and organizational/business qualities, AI-related quality has been added to address the needs of the AI era.

These quality attributes, as cross-cutting concerns, should ideally be handled separately from domain structure and domain logic through separation of concerns. Ideally, they should be implicitly realized through DSL configuration and the execution platform.

SimpleModeling, through Cozy and CNCF, encapsulates these quality attributes and provides a framework that allows developers to focus on domain structure and domain logic.

Asynchronous Abstraction

The reactive characteristics required of cloud applications and the multi-server environments provided by cloud platforms inevitably make asynchronous processing essential.

To develop asynchronous processing easily and operate it safely, it is essential to adopt a CQRS-based application architecture along with support from the execution platform.

When the execution platform abstracts:

Synchronous calls
Asynchronous messages
Event reception

component design is liberated from specific communication mechanisms. CNCF provides a framework to support this abstraction.

Summary

In this article, we argued that through the combination of a DSL and an execution platform, CBD becomes an implementable structural reality.

Conventional CBD was powerful as a concept, but its connection to implementation technologies was weak, often leaving it at the level of ideal theory.

However, when the following elements are in place,

Rigorous structural definition through DSL
Structural guarantees provided by the execution platform
Alignment with cloud-native architecture
Externalization of cross-cutting concerns
Asynchronous abstraction

CBD evolves from a design philosophy into an executable architectural unit.

CNCF serves as the execution platform for this purpose, and Cozy as the structural definition language.

Within the development stack of the AI era, CBD is repositioned once again as a central technology.

References

In Site

Glossary

BoK (Body of Knowledge): At SimpleModeling, the core knowledge system for contextual sharing is called the BoK (Body of Knowledge). The goal of building a BoK is to enable knowledge sharing, education, AI support, automation, and decision-making assistance.
CBD (Component-Based Development): Component-Based Development (CBD) is a software development approach in which systems are constructed and reused through components that define clear responsibilities, contracts, and interfaces. Components are designed to be independent and replaceable, enabling loosely coupled architectures that improve maintainability and reusability. In the logical model, a component serves as an abstract structural unit defining functionality and contracts; in the physical model, it corresponds to implementation and deployment units.
Component: A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.
Competency: A human capability required to perform certain Activities effectively. Competencies define skills, experience, and knowledge levels associated with roles.
literate model: A Literate Model is a “readable model” that integrates model structure with natural-language narrative (structured documentation). It extends the idea of literate programming into the modeling domain, unifying structure (model) and narrative (structured text) into a single intelligible artifact interpretable by both humans and AI. The concept of “Literate Modeling” has been explored previously by some researchers and developers, mostly as an approach to improve documentation or code comprehension. However, those attempts did not establish a systematic modeling methodology that integrates models, narrative, and AI assistance as a unified framework. The Literate Model is a modeling concept newly systematized and proposed by SimpleModeling for the AI era. Building upon the ideas of literate modeling, it redefines them as an intelligent modeling foundation that enables AI-collaborative knowledge circulation and model generation. It is not merely a modeling technique but a framework that embeds human reasoning and design intent as narrative within the model, enabling AI to analyze and reconstruct them to assist in design and generation.
Cloud Native Component Framework (CNCF): Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applications—such as logging, error handling, configuration, and deployment—within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.
CML (Cozy Modeling Language): CML is a literate modeling language for describing Cozy models. It is designed as a domain-specific language (DSL) that forms the core of analysis modeling in SimpleModeling. CML allows model elements and their relationships to be described in a narrative style close to natural language, ensuring strong compatibility with AI support and automated generation. Literate models written in CML function as intermediate representations that can be transformed into design models, program code, or technical documentation.
DSL (Domain Specific Language): A DSL (Domain-Specific Language) is a language designed for a particular domain, enabling direct and concise expression of the domain’s concepts and structures. Compared to general-purpose programming languages (GPLs), DSLs offer a higher level of abstraction tailored for domain-specific problem solving and automation.
internal DSL: An internal DSL is a domain-specific abstraction built within the syntax and type system of a host language. It allows leveraging existing tooling and guarantees type safety, often used in Scala via functions, type classes, macros, and extension methods.
type safety: Type safety refers to the property of a programming language or system where operations are guaranteed to be used with values of the correct type. Type-safe code prevents invalid operations by detecting type mismatches at compile time (or runtime), reducing runtime errors and unexpected behaviors. Scala ensures type safety through strong static typing combined with type inference, enabling expressive yet safe programming.
error: A generic term used broadly in practice. In software engineering, it is ambiguous and may denote bugs or failures in general. In SimpleModeling, Error is treated as a broad label, with specifics clarified as Mistake, Defect, Fault, Failure, or Deviation.
observation: Observation is the recorded form of phenomena that are judged worthy of being noted and stored. Observations serve as the foundation for logging, monitoring, auditing, and troubleshooting.
validation: Validation is the activity of confirming that a system or product fulfills its intended use and stakeholder requirements.
external DSL: An external DSL is a domain-specific language with its own syntax and grammar, distinct from general-purpose languages. It is optimized for expressiveness and readability within a specific domain, often requiring a parser or compiler to be executed or translated.
Externalization: The SECI phase in which tacit knowledge is externalized into explicit knowledge such as language, models, and diagrams.
verification: Verification is the activity of confirming that an implementation conforms to its specified design or requirements.