How to Build Scalable Business Architecture: Standards, Reuse, and Continuous Refactoring

Motivation

When launching a new application or maintaining an existing one, developers often feel lost due to fragmented business logic, insufficient architectural constraints, and the loss of technical knowledge over time. The article aims to provide guidance for these challenges.

Root Causes of Fragmented Architecture

Frameworks are too flexible, offering engineering conventions but leaving business design open, leading to many implementation choices.

Insufficient architectural constraints: different developers, varying design mindsets, and project pressures cause divergent designs.

The author likens framework constraints to legal rules and design principles to moral standards, suggesting a "design specification" for business developers similar to Alibaba's Java Development Manual.

Technical Debt and Knowledge Loss

Focusing on design outcomes rather than principles results in short‑term fixes that increase cost.

Prefer building new wheels over refactoring existing ones, causing duplicated effort.

Relying on documentation instead of tool‑based reuse makes onboarding and maintenance harder.

Proposed Business Architecture Design Specification

Standard : Unify business design framework to hide technical details.

Sediment : Continuously accumulate reusable "building blocks".

Refactor : Keep improving existing blocks to avoid duplication.

Integrate : Provide a flexible orchestration engine for rapid composition.

Standard – Reducing Detail Overhead

Using a supply‑chain finance example, the specification lists essential concerns such as domain modeling, process orchestration, data conversion, concurrency control, idempotency, exception handling, monitoring, and others.

Sediment – Capability Reuse

Technical capabilities accumulated by the AntChain application team include engineering conventions, read/write separation, and business‑level services such as online banking authentication and contract on‑chain integration.

Refactor – Continuous Optimization

Guidelines suggest analyzing historical context, clarifying problem scope, evaluating refactor feasibility, and collaborating with original creators to ensure sustainable improvement.

Integrate – Flexible Assembly

The service orchestration engine follows the design specification to hide technical details while allowing plug‑in components, business‑oriented configuration, and visual workflow definition.

Practical Standardized Architecture

Key components include:

Transaction Model – core business flow and state management.

Repository – generic data persistence operations.

Transaction Template – defines transaction boundaries and idempotency.

Generic Business Template – common exception handling, logging, and tracing.

Query Template – supports single, batch, and paginated queries.

Message – lightweight wrapper for messaging middleware.

Scheduler – wrapper for scheduling middleware.

Service Exposure – annotation‑driven API generation with documentation.

Other utilities – logging, exception handling, request/response types.

Domain‑Centric Modeling

Emphasizes that domain modeling is the core of business development. It outlines domain entities, repositories, services, transaction entities, and transaction repositories.

Service Orchestration Engine – "Blocks + Glue"

The engine enforces business model constraints, manages repository behavior, composes domain services, allows flexible state insertion, and supports reusable "blocks" across workflows.

Conclusion

The article advocates using standards to constrain technical details, tool‑based enforcement over pure documentation, continuous refactoring instead of reinventing wheels, and prioritizing domain modeling with DDD principles to improve productivity and maintainability.