概述

系统是由相互作用相互依赖的若干组成部分结合而成的，具有特定功能的有机整体，而且这个有机整体又是它从属的更大系统的组成部分。 – 钱学森

架构则是系统的一个属性。

架构由三部分构成

职责明确的组件
组件间明确的关联关系
指导原则

架构3W

架构文档框架

架构具体设计

针对“WHAT”中要做的事情，进行具体的细化说明

业务架构

业务用例分析

从需求和当前业务进行分析，要产出几个业务要素：

业务目标
业务关系
业务用例
业务流程

其中有一些分析的方法论：

SWOT
PEST
波特五力

对于业务用例图，在构图的时候需要通过下面三个视角来考虑：

用户视角，看用户参与的对应业务功能
业务视角，看每个业务功能涉及的角色和用例
平台视角，看涉及的各个业务功能

在设计每个业务用例图时，有3要素

找用户
找功能。用户参与某个业务，需要提供哪些具体的业务能力
描述。xxx用户使用/需要xxx功能

业务流程图

结合业务关系，站在业务用户视角下，描述业务流程

业务流程中应体现出，相关角色及其业务活动
应体现出完整的业务生命周期

信息架构（领域架构）

DDD相关概念

设计	概念	含义
领域划分	领域	明确业务范围，解决实际问题相关的所有东西的集合	L0:BG粒度，例如支付宝、财保
	子域	子域是领域的一部分，领域可能非常复杂，DDD会将领域进一步划分成更小力度的小问题，也就是子域。	L1:例如收单、结算、支付平台
	限界上下文	限界上下文是一个显式的概念性边界，领域模型都存在于这个边界之内，出了这个边界就不能确保这个含义。而上面提到的通用语言必须限制在这个限界上下文之中。	L2:保障业务语言无二义性。子域内部划分，粒度可以和系统、复杂模块划分。
	上下文映射	领域与领域之间交互
领域模型服务	实体	是拥有唯一标识和状态，具有生命周期的业务对象。	建模方法: 用例分析法四色建模法事件风暴法
	值对象	值对象用来描述领域的特定方面，没有标识符的对象。值对象本质上就是一个集合，用于描述目的、具有整体概念和不可修改的属性。
	领域服务	领域中一些操作无法归类到实体对象或值对象的概念。代表了领域中的一个重要的行为。这些操作或动作往往会涉及到多个领域对象，并且需要协调这些领域对象共同完成这个操作或动作
	领域事件	某个领域中重要的状态变化或业务事件的一种抽象描述，用来描述领域内发生的某件事情，如某个对象的状态变化、某个操作的执行结果等