应用架构（六铢）业务能力架构：用来分析业务，业务概念架构是指拥有哪些业务模块，且各自的能力是什么，这张图有助于我们分析和

架构定义

职责明确的模块或者组件
组件直接的关联关系非常明确
需要有约束和指导原则

架构推导

自顶向下: 需要知道整体
自底向上: 演绎归纳

两个阶段

分析：也是我们常说的问题空间领域建模，关键的一步是业务概念模型的输出
设计：解决方案空间建模，以及应用逻辑架构。

自底向上的推导（业务中主要使用）

底层的模型是通过建模方法演绎出来
逻辑架构中的各个模块是通过归纳的方法推导出来

怎么才能推导？

业务素材: 需要解决问题所在的领域
技术素材: 我们在技术领域不断的钻研，不断的扩展边界

业务架构推导

业务概念模型：问题空间领域模型，信息模型是同样的意思，这个层次上的实体我们称之为概念实体，这部分内容是用在需求和业务分析上的，讨论业务概念模型时完全不需要考虑软件的实现，这个过程是一个分析过程
系统模型：解决方案空间领域模型，逻辑模型是同样的意思，这个层次上的实体，我们称之为系统实体，或者逻辑实体，就是各种类，这个是用在软件设计和软件研发上的。
存储模型：数据模型，物理模型，在这里也是同样的意思，这个层次上的实体，我们称之为数据实体，或者物理实体，也是用在软件设计上。

用例集合推导概念模型

根据用例集合推导业务概念模型
根据用例中的动词和量词推导业务概念模型的关联关系
在特定的边界内根据模型的职责归纳子域

对业务概念模型进行归纳

通过名词定义来进行归纳思维概念:多个模型都在围绕某个名词
通过内聚的度量公式来进行归纳: 模型和模型连线 失去了最底层合理且正确的演绎，上层的归纳掌握的再好，也很难得出合理的结果。

业务流程

这个地方主要明确的就是边界和异常分支等等

基础逻辑架构推导（软件设计）

业务概念架构
模型（系统模型和数据模型）
流程（系统调用流和数据流）

在业务概念架构的基础上推演应用逻辑架构
根据流程和系统模型来完善应用逻辑架构。
横向提炼模块的问题：要实现业务模块，需要什么非业务模块的支撑，比如监控，报警，配置等等，而这部分内容往往还是可复用的。在上述动画中，可以理解成移动到最右侧的部分
纵向提炼模块问题：有类似职责的模块在技术实现上是否可以提炼成可复用内容，提炼的结果可能是：
- 独立的服务复用
- 或者二方库复用
还有一些模块是为了支撑性能或者稳定性的，并非是从业务概念模型提炼而来，如图中深蓝色的模块。

对流程进行归纳

业务概念架构 -> 逻辑架构骨架 -> 根据流程来进行模块划分

先根据业务流程，分解出系统时序图，根据时序图开始对模块进行归纳，从而得到粒度更大的模块。

对系统模型进行归纳

业务概念模型一般可以直接转换为系统模型，但是系统模型并不只是业务领域相关的模型 还需要结合粒度

流程和模块一样，也是有粒度的，相同粒度的流程节点放在一起才更加容易推导出合理的架构模块

对根据性能，稳定性提炼

除了业务，技术上的考量也需要

架构的约束

基本约束：软件工程领域常见的各种软件设计原则
职责约束：模块，子模块，模型的职责相关约束，尤其是核心的模型和核心主模块是在一定时间内是比较稳定的
非业务功能性约束：稳定性，性能，成本

业务约束

这些基本约束在高粒度模块中一般很少被提及，高粒度模块之间的约束关系是根据业务中的思维概念提炼而来
这样的约束并不是一层不变的，尤其是在业务系统中，业务理解发生了变化，这样的约束也会随之变化

逻辑架构复用

跟业务无关：框架库
业务相关：
- 系统模型：营销活动规则
- 流程：
- 计算模型

抽象提炼

有类似的模型或者属性
有类似的流程
有类似的数据结构和算法

逻辑架构分层

逻辑架构分层不是指工程骨架分层

业务概念架构
逻辑架构中上下左右模块之间存在依赖关系
逻辑架构是分片的，一般来说同一个层次会存在多个模块

区别

目的上：逻辑架构中的分层是逻辑架构中各模块间的依赖层次关系
形式上：某个逻辑架构中某个层次上的应用内部依然是存在工程骨架分层的

逻辑架构分粒度

上述的树形结构，只能描绘出模块和父模块，子模块的关系，但是不能完整的描绘出模块之间的关系，是处于同一层次，还是处在不同层次

模块粒度落地

不同的粒度

可能是子包
可能是顶层的包
可能是应用
可能是一组应用的集合，负责某种职责
也可能是某个平台（如营销平台，商品中心等）
更有可能更大层次的平台，比如 B2C

巨型架构粒度（中台）

抽象中台依据

多个业务线有无重复的流程抽象，
有无重复的领域模型抽象，
有无重复的计算模型（数据结构和算法）等等，
有无重复的辅助性设施。他们是否在重复建设，等等。

考量维度

效率
稳定性
性能

方法论：自底向上

自顶向下

当我们的目标（比如说业务目标）或者结论是非常高粒度的时候，需要分解
在规划未来时一般会用到类似的自顶向下的方法，产出我们宏观结论。

自底向上

产品方案已经明确，程序员需要理解这个业务需求，并根据产品方案推导出架构
演绎和归纳

演绎

演绎就是逻辑推导，越是底层的，越需要演绎

从用例到业务模型就属于演绎
从业务模型到系统模型也属于演绎
从系统模型演绎抽象出物理存储模型
根据目前的问题，推导出要实施某种稳定性措施，这是也是演绎

演绎推导的层次越深，分支逻辑越多，越能穿透迷雾，看问题就越透彻，说明功力越深厚。

归纳

事物的某个维度来进行归类，越是高层的，越需要归纳

问题空间模块划分属于归纳
逻辑架构中有部分也属于归纳
根据一堆稳定性问题，归纳出，事前，事中，事后都需要做对应的操作，是就是根据时间维度来进行归纳。

总结

领域建模是抽象和架构的重要方法
归纳和演绎也是抽象及架构的重要方法
自顶向下推演也是架构的重要方法

总的来说

1）架构问题是我们工作中常见的问题，我们要注意识别并定义架构中的问题
2）业务概念模型的产出是通过具体的方法演绎出来的
3）业务概念架构的产出是通过具体的方法归纳出来的
4）系统模型和数据模型的产出是通过具体的方法演绎出来的
5）应用逻辑架构的产出是通过对前面的产出归纳和演绎出来的
- 架构内模块的构建，模块的依赖关系，及约束
- 模块的粒度，父子模块的归纳
- 提炼可复用模块
- 纯技术模块的产生
- 逻辑架构的分层
- 物理架构的演进受逻辑架构的影响
- 研究业界现有的技术架构
6）应用逻辑架构推导所使用的归纳和演绎方法涉及到很多具体的知识

应用架构（六铢）