开发人员必须钻研领域以获取业务知识。他们必须磨砺其建模技巧，并精通领域设计。
Eric《Domain-Driven Design》
所谓的领域建模，是一种通过日常不断实践，来强化开发人员思维，逼迫开发人员进入深度思考的过程，并通过在这个过程中的不断锤炼，可以使得开发人员形成结构化思考方式的方法论。
领域模型
概念模型
现实世界中对象可视化表达
问题领域 > 业务领域概念 > 建立业务领域概念之间的关系
“物质基础决定上层建筑”
马克思
从架构上来说，领域模型是处于应用架构的最底层，Domain层涵盖了模型治理、流程抽象、流程治理等方面的知识。我们可以很清楚地看到，如果领域模型没有把控好，那么就相当于大楼地基没有打好，带来的后续建筑或是维护成本之高，是难以想象的。
Explore the problem space before thinking about the solution
https://mashhoodalam.com/2015/07/03/what-is-design-thinking-and-why-is-it-better/
先探索问题空间，然后再考虑解决方案。
首先使用发散思维, 探索有关利益相关者及其背景的所有不同观点，总结归纳出对利益相关者的共同理解，并使用聚合思维定义需要解决的问题。
这有助于在考虑“如何”和“什么”之前回答倡议的“为什么”。
抽象领域模型的具体步骤:
1.收集用例描述集合
一系列需求文字描述的用例集合
2.寻找概念
对用例描述进行语言分析，识别名词
3.添加模型关联
名词之间存在语义联系，则往往存在模型关联，例如上面的发布，联系了金牛和文章两个名词
4.属性完善
形容词完善，例如上面的领域建模相关，如果文章存在标签属性，那么它的值在我们这个用例里就是领域建模。
实际的工程中领域建模，会比这个复杂。例如还存在子域划分、模型组合等手段。
学会了领域建模，有助于提升自己的抽象能力。如果在早期就有了抽象的思维，你会发现随着时间推移，你所需要建立的“原则”越来越少，已有的原则会越来越完善。
架构概论
1. 什么是架构
架构就是对系统中的实体以及实体之间的关系所进行的抽象描述，是一系列的决策。
架构是结构和愿景。
系统架构是概念的体现，是对物/信息的功能与形式元素之间的对应情况所做的分配，是对元素之间的关系以及元素同周边环境之间的关系所做的定义。
做好架构是个复杂的任务，也是个很大的话题，本篇就不做深入了。有了架构之后，就需要让干系人理解、遵循相关决策。
2. 什么是架构图
系统架构图是为了抽象的表示软件系统的整体轮廓和各个组件之间的相互关系和约束边界，以及软件系统的物理部署和软件系统的演进方向的整体视图。
3. 架构图的作用
一图胜千言。要让干系人理解、遵循架构决策，就需要把架构信息传递出去。架构图就是一个很好的载体。那么，画架构图是为了：
解决沟通障碍
达成共识
减少歧义
4. 架构图分类
搜集了很多资料，分类有很多，有一种比较流行的是4+1视图，分别为场景视图、逻辑视图、物理视图、处理流程视图和开发视图。
画架构图遇到的常见问题
1. 方框代表什么？
为什么适用方框而不是圆形，它有什么特殊的含义吗？随意使用方框或者其它形状可能会引起混淆。
2. 虚线、实线什么意思？箭头什么意思？颜色什么意思？
随意使用线条或者箭头可能会引起误会。
3. 运行时与编译时冲突？层级冲突？架构是一项复杂的工作，只使用单个图表来表示架构很容易造成莫名其妙的语义混乱。
推荐的画图方法
C4 模型使用容器（应用程序、数据存储、微服务等）、组件和代码来描述一个软件系统的静态结构。这几种图比较容易画，也给出了画图要点，但最关键的是，我们认为，它明确指出了每种图可能的受众以及意义。
下面的案例来自 C4 官网，然后加上了一些我们的理解，来看看如何更好的表达软件架构
1. 语境图(System Context Diagram)
这是一个想象的待建设的互联网银行系统，它使用外部的大型机银行系统存取客户账户、交易信息，通过外部电邮系统给客户发邮件。可以看到，非常简单、清晰，相信不需要解释，都看的明白，里面包含了需要建设的系统本身，系统的客户，和这个系统有交互的周边系统。
用途
这样一个简单的图，可以告诉我们，要构建的系统是什么；它的用户是谁，谁会用它，它要如何融入已有的IT环境。这个图的受众可以是开发团队的内部人员、外部的技术或非技术人员。即：
构建的系统是什么
谁会用它
如何融入已有的IT环境
怎么画
中间是自己的系统，周围是用户和其它与之相互作用的系统。这个图的关键就是梳理清楚待建设系统的用户和高层次的依赖，梳理清楚了画下来只需要几分钟时间。
2. 容器图(Container Diagram)
容器图是把语境图里待建设的系统做了一个展开。
上图中，除了用户和外围系统，要建设的系统包括一个基于java\spring mvc的web应用提供系统的功能入口，基于xamarin架构的手机app提供手机端的功能入口，一个基于java的api应用提供服务，一个mysql数据库用于存储，各个应用之间的交互都在箭头线上写明了。
看这张图的时候，不会去关注到图中是直角方框还是圆角方框，不会关注是实线箭头还是虚线箭头，甚至箭头的指向也没有引起太多注意。
我们有许多的画图方式，都对框、线的含义做了定义，这就需要画图的人和看图的人都清晰的理解这些定义，才能读全图里的信息，而现实是，这往往是非常高的一个要求，所以，很多图只能看个大概的含义。
用途
这个图的受众可以是团队内部或外部的开发人员，也可以是运维人员。用途可以罗列为：
展现了软件系统的整体形态
体现了高层次的技术决策
系统中的职责是如何分布的，容器间的是如何交互的
告诉开发者在哪里写代码
怎么画
用一个框图来表示，内部可能包括名称、技术选择、职责，以及这些框图之间的交互，如果涉及外部系统，最好明确边界。
3. 组件图(Component Diagram)
组件图是把某个容器进行展开，描述其内部的模块。
用途
这个图主要是给内部开发人员看的，怎么去做代码的组织和构建。其用途有：
描述了系统由哪些组件/服务组成
厘清了组件之间的关系和依赖
为软件开发如何分解交付提供了框架
4. 类图(Code/Class Diagram)
这个图很显然是给技术人员看的，比较常见，就不详细介绍了。
案例分享
下面是内部的一个实时数据工具的架构图。作为一个应该自描述的架构图，这里不多做解释了。如果有看不明白的，那肯定是还画的不够好。
画好架构图可能有许多方法论，本篇主要介绍了C4这种方法，C4的理论也是不断进化的。但不论是哪种画图方法论，我们回到画图初衷，更好的交流，我们在画的过程中不必被条条框框所限制。简而言之，画之前想好：画图给谁看，看什么，怎么样不解释就看懂。