How to Build a Business Architecture Framework: From Value Streams to Domain Modeling

Background

We are the CRO business technology team that has been handling merchant risk‑management for four years. As a vertical business‑tech group, we often face questions about the differences between business and platform technology and how to understand and design business solutions in a fast‑paced environment. This article summarizes four years of experience, extracting a basic thinking framework from both business and technology perspectives for developers.

Business Architecture

Purpose : Explain how business development should focus on and analyze business problems and how to use that understanding to guide system design.

What it does : Emphasize a global view—seeing the whole picture rather than just methods—by looking at three aspects:

Seeing the thing : From a macro perspective, the "thing" is the source of value, business strategy, goals, and value; from a micro perspective, it is the business process. Example: helping merchants handle risk at low cost to reduce operating expenses and improve platform competitiveness.

Understanding the people : Identify stakeholders, classify their needs, and prioritize. The key is to understand what users want from their perspective.

Clarifying responsibilities : Define rights and duties of each role in the process, which informs product capability design (e.g., different merchant employee roles require different permissions and functions).

Value Stream / Capability Mapping

Value stream describes the end‑to‑end value delivery from the stakeholder perspective. Capability is the ability a business needs to achieve a specific purpose. Mapping capabilities to each stage of the value stream highlights which capabilities are critical, partially met, or missing.

Role Analysis

Use UML use‑case diagrams to describe people and responsibilities. The business risk‑management domain has three roles, each with specific responsibilities, as shown in the diagram.

Application Architecture

Architecture defines component structure, relationships, and design principles that guide evolution over time.

Two common design methods are presented:

Top‑down : Adapt a standard solution to a specific problem, suitable when experienced designers can leverage existing domain models.

Bottom‑up : Start from detailed business details, inductively derive a solution. The article focuses on the bottom‑up approach.

Bottom‑up "Three‑step" Method

Induction : Enumerate all problem details (scenarios) and then classify them.

Abstraction : Analyze classified scenarios to derive a design (e.g., domain model or process framework).

Verification : Simulate scenarios top‑down to evaluate whether the design meets current and future needs.

Domain Modeling

The focus is on sub‑domain division. Over‑segmentation (many tiny sub‑domains) or unclear boundaries indicate poor design. A clear example shows how to identify sub‑domains by examining connection density.

Process Modeling

Process modeling defines three tasks: set stages, define responsibilities, and define interactions.

Set stages : Design processing steps for a business scenario, keeping granularity consistent across similar processes.

Define responsibilities : Clarify the scope of each stage to establish clear boundaries and avoid a “big mud ball”.

Define interactions : Organize communication between stages—vertical within a stage, horizontal between stages.

Summary

The proposed business architecture pattern provides a framework that emphasizes a business‑centric perspective and a disciplined design process (top‑down or bottom‑up). Each design decision is derived from value‑driven analysis and scenario verification, helping developers build robust, scalable solutions.