How to Standardize Business Architecture: A Layered Design Blueprint

Background

In the previous article "How Business Teams Can Unify Architecture Design Style?" a design specification for business architecture was discussed, aiming to constrain technical details with standards, enforce standards through tools rather than documents, continuously refactor instead of reinventing wheels, and emphasize business modeling. This article expands on those ideas with concrete technical details and answers many questions raised earlier.

Overview

The diagram (e‑commerce product example) shows a standard framework with multiple design layers. The following sections explain each layer’s specifications and construction methods.

Product Mode Layer

Describes the complete feature list via product contracts, identifies applicable scenarios through signatories, and groups contracts to define independent functional domains. Assembling contract groups enables rapid product construction.

Business Model Layer

Standardizes modeling scenarios to reduce stylistic differences among developers, linking repository management, business processes, and components. Focus shifts to business expression, minimizing attention to implementation details, allowing fast model building based on domain analysis.

Business Process Layer

Uses a standard process framework to describe the full execution flow of a business model. Business components are high‑cohesion function sets that adapt model information to standard parameters for infrastructure execution. A process engine creates and manages instances, handling actions, state transitions, conditional jumps, and exception branches, enabling rapid process assembly.

Data View Layer

Provides a standard data‑flow mechanism for customizable view requirements. A data‑flow subscriber gathers data from sources such as blockchain, business DB, file system, or offline tasks. A consumer processes raw data into presentation, verification, or metric data. This ensures stable, low‑cost data access while allowing developers to customize business logic without affecting domain modeling.

Specification Details

1 Product Mode

Product Contract

Describes the complete business model from a global perspective, including target customers, dependent domains, and service outputs.

The contract is a static description file whose usage scenarios are defined by a list of signatories.

Example

In an e‑commerce product, a merchant‑signed contract defines listing requirements, while a joint merchant‑platform‑buyer contract applies to order placement.

Construction

Adding/Modifying

Low‑code: Design product templates in the product center, define contract groups and contents based on business needs.

Implementation: Write corresponding contract and signatory model classes in the business system, integrate with the product center for creation, invalidation, and querying.

2 Contract Group

Specification

Describes a highly cohesive business domain’s functions and configuration, including models, services, processes, and components.

Multiple contract groups together form a deliverable product contract.

Example

In an e‑commerce product contract, the product group defines listing flow and configuration, the order group constrains order creation flow and services, and the return group describes return flow and customer service.

Construction

Adding/Modifying

Low‑code: Define a contract group as metadata, describing model, process, and configuration with key‑path, value type, and constraints.

Implementation: Hard‑code model classes, repository, and converters; or use metadata to generate them automatically.

3 Business Domain

Model

A business model describes core entities within a domain and connects processes and components.

Models may reference other models but should avoid circular dependencies.

A complete model includes data, view, conversion, and repository definitions.

Example

A return business model uses a return order to drive the process; components obtain necessary information from the return order to execute refund, notification, etc. The return order links to a forward order but not vice‑versa. The model maps to a main table and multiple detail tables, with the repository handling bidirectional reads/writes.

Construction

Hard‑code: Write Model, DO, Mapper, VO, Converter, Repository, etc.

Low‑code: Describe metadata to auto‑generate DO/VO/Mapper/Converter; use a base repository component to generate instances from metadata.

Service

Specification

Business services aggregate functions per domain, exposing minimal method units to internal and external callers.

Each service must have a definition standard (annotations/AOP) providing metadata for discovery, documentation, permission control, and stability guarantees.

Service inputs are limited to a system parameter object and a business parameter object, both designed for end‑to‑end traceability.

Services return a Result object; error codes stay within the defined range, and business data is returned as POJO or VO.

Services are not limited by caller source; simple conversion logic and authorization are added at the integration layer.

Write services require transaction management.

Example

public interface DemoOrderService {
    /**
     * Order application
     * @param sysParam sysParam
     * @param bizParam bizParam
     * @return result
     */
    @ApiFunction(apiType = ApiType.SUBMIT, funcBiz = "ORDER", funcAction = "APPLY",
            returnType = OrderApplyResponse.class, errorCodeType = CommonErrorCodeEnum.class)
    CommonResult<OrderApplyResponse> apply(ApiReqSysParam sysParam, OrderApplyInfo bizParam);
}

Construction

Adding/Modifying

Low‑code: Generate interface, method, error codes, and POJOs from metadata.

Implementation: Hard‑code for unique or complex requirements; otherwise use templates.

Usage: Assemble request → call → handle result (hard‑code) or map POJOs via metadata (low‑code).

4 Flow

Specification

A Flow describes a complete business process based on a single business model, advancing through multiple sub‑steps.

Multiple Flow definitions can exist for the same model to satisfy different business patterns.

Flow consists of transitions, components, and actions; each operation triggers an action on a component, completing components and transitions accordingly.

The goal is to decompose complex processes into atomic actions that are decoupled.

Flow execution requires integration with service/message/scheduling entry points.

Flow depends on external transaction management and model repositories for loading and persisting state.

Example

<?xml version="1.0" encoding="UTF-8"?>
<flow id="OrderApply" version="001" desc="Standard order flow">
    <config>
        <model class="xxx.xxx.Order"/>
    </config>
    <init type="INIT" desc="Initialize">
        <action operate="INIT.INIT"/>
    </init>
    <transitions>
        <transition from="INIT" to="ITEM_OCCUPIED">
            <component type="ITEM" desc="Deduct inventory">
                <action operate="ITEM.OCCUPY"/>
            </component>
        </transition>
        <transition from="ITEM_OCCUPIED" to="DISCOUNT_OCCUPIED">
            <component type="DISCOUNT" desc="Deduct discount">
                <action operate="DISCOUNT.OCCUPY"/>
            </component>
        </transition>
        <transition from="DISCOUNT_OCCUPIED" to="SUCCESS">
            <component type="NOTIFY" desc="Order success notification">
                <action operate="NOTIFY.SELLER"/>
                <action operate="NOTIFY.BUYER"/>
            </component>
        </transition>
    </transitions>
</flow>

Construction

Adding/Modifying

Low‑code: Flow execution is supported by a base component; define Flow configuration files dynamically from component templates and model data, with version control to avoid compatibility issues.

Usage: Initialize Flow from contract configuration, then trigger actions via templated code.

5 Component

Specification

Components aggregate a class of business actions, designed around functionality rather than a specific model.

Actions are atomic units; their granularity is judged by decoupling and reusability, typically depending on one or more infrastructure/services.

Components can be customized via adapters or fully overridden for exclusive use.

All core business logic (validation, idempotency, model changes, calculations, external calls) should reside in the component layer or below.

Components require a definition standard (XML/annotations) describing supported actions and models.

Example

Discount Component Interface

public interface BizModelDiscountComponent<T extends BizModel> extends BizModelComponent<T> {
    /** Occupy discount */
    void occupy(FlowContext context);

    /** Refund discount */
    void refund(FlowContext context);
}

Component Template Configuration

<componentTemplate type="DISCOUNT" desc="Discount">
    <interface name="xxx.xxx.BizModelDiscountComponent"/>
    <bizModelMappings>
        <bizModelMapping>
            <bizModel class="xxx.xxx.Order"/>
            <componentEntry name="orderDiscountComponent"/>
        </bizModelMapping>
        <bizModelMapping>
            <bizModel class="xxx.xxx.RefundOrder"/>
            <componentEntry name="refundOrderDiscountComponent"/>
        </bizModelMapping>
    </bizModelMappings>
    <triggerMappings>
        <triggerMapping>
            <triggerTemplate operatePostfix="OCCUPY"/>
            <methodEntry name="occupy"/>
        </triggerMapping>
        <triggerMapping>
            <triggerTemplate operatePostfix="REFUND"/>
            <methodEntry name="refund"/>
        </triggerMapping>
    </triggerMappings>
</componentTemplate>

Component Implementation (Hard‑code)

public abstract class AbstractBizModelDiscountComponent<T extends BizModel> implements BizModelDiscountComponent<T> {
    @Resource
    private DiscountApiService discountApiService;

    @Override
    public void occupy(FlowContext context) {
        T bizModel = (T) context.getBizModel();
        getDiscountAdapter().processOnOccupyResult(bizModel,
                discountApiService.occupy(getDiscountAdapter().toOccupyInfo(bizModel, new AdapterConfigInfo())));
    }

    @Override
    public void refund(FlowContext context) {
        T bizModel = (T) context.getBizModel();
        getDiscountAdapter().processOnRefundResult(bizModel,
                discountApiService.refund(getDiscountAdapter().toRefundInfo(bizModel, new AdapterConfigInfo())));
    }

    @SuppressWarnings("unchecked")
    protected BizModelToDiscountAdapter<T> getDiscountAdapter() {
        return (BizModelToDiscountAdapter<T>) FlowInstanceFactory.instanceBizAdapter(
                "DISCOUNT", (Class<? extends BizModel>) TypeUtils.getRealClassOfParameterizedType(this));
    }
}

Construction

Adding/Modifying

Hard‑code: New components require design thinking and trade‑off analysis; later abstract into templates.

Low‑code: Reuse existing component templates by configuring contract groups; only adapter configuration changes are needed.

Usage

Low‑code: Flow base assembles, discovers, and triggers components automatically.

6 Infrastructure

Specification

Infrastructure aggregates high‑reuse, low‑change external service capabilities as minimal method units for business services/components.

It can wrap channel capabilities (e.g., merchant channels) or generic technical services (e.g., discount, product, customer).

Unlike business services, core functionality is provided by external services; the system handles parameter assembly, scenario identification, result parsing, and exception handling.

Infrastructure interfaces accept standard POJOs and return results wrapped in a Result object, shielding callers from external exceptions.

Example

public interface NotifyGateway {
    /** Notify via email/SMS/internal message */
    CommonResult<NotifyResponse> notify(NotifyInfo notifyInfo);
}

Construction

Adding/Modifying

Hard‑code: Integration is usually one‑off; low‑code benefits are limited.

Usage

Hard‑code: Assemble parameters, invoke, and parse results in service/component code.

7 Model Adaptation

Specification

Adapters bridge business models with infrastructure/services, handling bidirectional conversion between model objects and service parameters.

In templated components, the call chain is fixed; each model only needs to implement its adapter to achieve customization.

Adapters are usually paired with product contract configurations to describe mapping relationships.

Example

public abstract class BizModelToDiscountAdapter<U extends BizModel> implements BizModelAdapter<U> {
    @Override
    public final String getType() { return "DISCOUNT"; }
    /** Generate discount request */
    public abstract OccupyInfo toOccupyInfo(U bizModel, AdapterConfigInfo configInfo);
    /** Process discount result */
    public abstract void processOnOccupyResult(U bizModel, CommonResult<OccupyResponse> result);
    // ...
}

For an order model needing discount deduction, implement:

@BizAdapter
public class OrderToDiscountAdapter extends BizModelToDiscountAdapter<Order> {
    @Override
    public List<ConfigDef> getConfigDefs() {
        return Lists.newArrayList(ConfigEnum.DISCOUNT_TYPE, ConfigEnum.DISCOUNT_TERM);
    }
    @Override
    public OccupyInfo toOccupyInfo(Order bizModel, AdapterConfigInfo configInfo) {
        // Parse selected discount type and build request
        return new OccupyInfo();
    }
    @Override
    public void processOnOccupyResult(Order bizModel, CommonResult<OccupyResponse> result) {
        // Recalculate order amount based on successful discount
    }
    // ...
}

Construction

Adding/Modifying

Hard‑code: Define adapter once when component‑service relationship is established; rarely changes.

Low‑code: Use flexible contract configuration to describe mapping; once coded, only configuration maintenance is needed.

Usage

Hard‑code: Adjust adapters when new service patterns appear.

Conclusion

The article summarizes the layered design, emphasizing that standards are not rigid rules but shared conventions that enable consistent modeling, parallel development, clearer scope, and easier refactoring. While initial adoption may add overhead, the long‑term benefits in collaboration, onboarding, and efficiency become evident as teams grow.