System Analysis and Architecture Design: Principles, Modeling, and Implementation Guidelines

Overview

According to the definition in "System Architecture", a system is a collection of entities and the relationships among them, whose overall functionality exceeds the sum of the individual parts. In our context a system may be an app, a web application, a service, a batch program, or a large system that includes all of these.

As the integration of the Internet with traditional enterprises deepens, business complexity grows. How should we design such systems?

From Product to Development

There is a huge gap between product prototyping and development implementation, especially for complex business requirements. Typically at least two steps are needed: business analysis and architecture design.

Business analysis focuses on domain modeling and answers "how to achieve the business". Architecture design focuses on technical implementation and answers "how to achieve it technically". Both influence each other and often require iterative adjustments and documentation updates.

Basic Principles

The analysis and design process repeatedly abstracts and encapsulates system entities. Abstraction turns business concepts into software elements (systems, modules, classes); encapsulation defines element boundaries, hides implementation, and exposes interfaces.

The core principles are abstraction and encapsulation, which are reflected in SOLID, DRY, high cohesion & low coupling, design patterns, etc.

Business Analysis

Analysis Methods

Business analysis builds a domain model that produces an analysis model describing logical design and structure, typically including use cases, entity models, interaction flows, and state transitions. The model helps non‑technical stakeholders understand the system and provides a foundation for developers.

The process is iterative: for complex, multi‑domain requirements, start with a high‑level system analysis, then decompose into subsystems for detailed modeling.

During analysis, adjust models when high coupling is discovered, e.g., by re‑abstracting entities.

Clarify Business Requirements

Identify stakeholders and their concerns.

Define who uses the system and what they do.

Determine the functional scope – what is included and what is excluded.

Stakeholders include users, suppliers, partners, operations, sales, management, regulators, as well as development, testing, and operations teams.

Roles may be further refined; for example, a clinic appointment system involves doctors, patients, and clinic staff.

Example use‑case diagram for a clinic appointment system:

Roles: doctor, patient, clinic employee.

Use cases: schedule appointments, manage appointments, book/cancel with doctors.

Build Entity Model

Entity modeling defines the system's entities and their relationships:

Clarify business concepts and unify terminology.

Abstract business entities such as events, people/roles, locations, and things.

Identify relationships: inheritance, aggregation, association, etc.

The result is an ER (Entity‑Relation) model, often visualized with class or component diagrams.

Analyze Business Scenarios

Scenario analysis determines the interaction process of participants in a concrete business situation, refining the analysis model.

Identify business rules and flow.

Define state‑transition logic for complex states.

Enrich the entity model description.

Consider all paths, including exceptional ones, and document them with flowcharts, swim‑lane diagrams, or UML activity/state diagrams.

Example appointment status diagram:

Architecture and Technical Design

Architecture Approach

Architecture design need not dive into low‑level details but must consider the whole system to manage risk. The depth of detail is a judgment call for the designer.

Uncertain aspects should be documented and validated early, possibly with prototypes.

Commonly used 4+1 view model (logical, development, process, physical, plus scenarios) or a viewpoint‑based approach.

Determine Overall Architecture

Identify the system’s position and responsibilities within the larger context.

Define responsibilities of the system itself and of external systems.

This corresponds to the scenario view, treating the system as a black box and clarifying its scope and interactions.

Design Functional Modules

Define module boundaries.

Specify each module’s responsibilities and inter‑module relationships.

Modules can be organized by business functionality, implementation layers, or patterns such as CQRS, and are often depicted with UML component diagrams.

Clarify Architectural Concerns

Security: authentication, authorization, audit, data consistency.

Performance: response time, throughput.

Reliability: downtime, fault recovery, data backup.

Scalability: future changes and how to accommodate them.

Other: internationalization, usability, compliance.

Trade‑offs are inevitable; priorities must be set (e.g., performance vs. consistency).

Design Database Model

When the entity model is complete, the database model follows, though it may not be a strict one‑to‑one mapping. Consider normalization, redundancy, consistency, sharding, and possibly NoSQL options such as Elasticsearch or Cassandra.

Design Interfaces

Define API details, typically JSON over HTTP, but also consider message queues, etc. Documentation can be kept in Markdown, RAP, Swagger, or code‑generated specs.

Base the design on domain resources or services.

Balance granularity: too fine‑grained leads to many calls, too coarse reduces flexibility.

Describe usage from the caller’s perspective, using flowcharts, sequence or state diagrams as needed.

Document method, pre‑conditions, parameter meanings, error handling, and responses.

Scenario Implementation

With business scenarios, database model, and API defined, implementation becomes straightforward, though details such as offline tasks, network failures, cache invalidation, etc., must be addressed.

Example: a WeChat web payment flow can be expressed with a sequence diagram.

Other Considerations

Common handling: logging, error handling, coding standards, unit testing.

Data migration, synchronization, rollback strategies.

Deployment and release processes, especially for multi‑system migrations.

Monitoring and alerting, including special metrics.

Concurrency and large data volumes: performance and stress testing.

Cache design and placement.

Technology selection: evaluate pros and cons of new technologies.

Design Methods and Tools

UML

Object‑Oriented Analysis & Design (OOAD)

Domain‑Driven Design (DDD)

CQRS & Event Sourcing

References

Books

Analysis Patterns: Reusable Object Models (https://book.douban.com/subject/4832380/)

Software Architecture: Using Views and Viewpoints to Collaborate with Stakeholders (https://book.douban.com/subject/24530471/)

UML and Pattern Applications (https://book.douban.com/subject/1792387/)

Architecture Is the Future: Scalable Web Architecture, Processes, and Organization (https://book.douban.com/subject/26765979/)

Articles

From Use‑Case Analysis to Design Review: How We Design Business Systems (http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg)

How R&D Teams Write High‑Level and Detailed Design Documents (http://www.10tiao.com/html/249/201412/201657741/1.html)

Using UML for System Analysis (http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis)

Four‑Color Modeling for Domain Analysis (http://www.infoq.com/cn/articles/xh-four-color-modeling)

From Four‑Color Modeling to Boundary Paper‑Pen Modeling (http://insights.thoughtworkers.org/paper-pen-modeling/)

My Understanding of DDD (http://www.cnblogs.com/netfocus/p/5548025.html)

DDD Reference Architecture (http://blog.csdn.net/bluishglc/article/details/6681253)

DDD and Practice (http://www.infoq.com/cn/articles/cjq-ddd)

Thoughts on CQRS/EventSourcing Architecture (http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==∣=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027)

Fundamentals of Architecture Design (https://blog.dreamtobe.cn/2016/03/09/oo_architecture/)

Author: Zhang Yeming, CTO of Almond Doctor, senior programmer focusing on technology and team management. Source: https://mp.weixin.qq.com/s/JoKzg2vUe2IwX099xSFtFA