在对《企业应用架构模式》这本书有了一个系统的认识之后，我又大致读了一部分后半部分的内容，主要就是对模式的一个讲解：
模式
“模式”一词大家都在用，简单来讲就是我们通过实践发现的一些有价值的设计或者解决方案，这些方案能复制到类似的问题域中很好地解决问题，从而提升生产效率，他是通过实践找到的捷径。书中给出了Chirstopher Alexander给出的定义，我觉得很好：
模式描述一个不断重复发生的问题以及该问题解决方案的核心，这样我们能够使用该方案二不必做重复劳动。
所以，一个模式包含如下关键部分：问题上下文、核心解决方案。martin的书在讲后续的每个模式的时候，也据此将模式分成了几部分来介绍：模式名称、意图和概要、运行机制、使用时机、进一步阅读。
模式总结
事务脚本
模式概要：事务脚本使用过程来组织业务逻辑，每个过程处理来自表现层的单个请求，可以适用于简单的业务场景，可以加快开发速度，去掉繁琐的分层。
项目实践：实际项目中并没有遇到可以应用事务脚本的场景，通常意义上的企业应用，业务逻辑都不会太简单，也不是临时性的项目。
领域建模
模式概要：合并了行为和数据的领域对象模型，核心在于将易变的业务逻辑内聚在领域模型中。
标识域
模式概要：为了在内存对象和数据库之间维护标识而在对象内保存的一个数据库标识域。标识域满足两个特性：唯一性、不可变性。
可以根据DDD中介绍的实体和值对象来做区分，如果是实体，那么建议是用业务主键，比如“User”和“Order”，分别可以使用userNo和orderNo来标识。而对于值对象，可以直接使用其物理主键作为标识域，比如“用户点赞信息”，可以使用物理主键id作为标识域，当然也可以使用业务联合主键（userNo和postNo）作为标识域，但是会增加复杂度，不可取
另外，通常情况下，我们可以将物理主键命名为以Id结尾，将业务主键命名为No结尾；
很多服务场景，需要将实体的标识域暴露给调用方，就要考虑安全性问题，如果你的标识域是顺序递增的long型主键，那么很可能会被攻击者遍历，从而带来一些安全风险，这时候可以做如下两种考虑：标识域不再使用顺序递增的long型主键，而是使用不可遍历的uuid等；如果没法将标识域更改为uuid，那么考虑新建一个域，存储专门供外部使用的uuid值。比如：我们在用户系统中便为User创建了一个使用uuid值的UnionId字段。
不建议前后端将标识域明文传递，尤其是越权访问会带来数据泄露问题的场景，比如：查询用户信息，这时候实体的标识域应当考虑从会话中获取，避免越权访问带来的数据风险
项目实践：订单系统中，我们使用业务主键orderNo作为Order实体的标识域，且由于orderNo形式为：yyyyMMddHHmmssSSS+sequence，被遍历的成本非常高，因此直接暴露在外使用。
外键映射
模式概要：把对象间的关联映射到表间的外键引用。
项目实践：社区系统中的“帖子”实体持有“用户”实体的标识域，在数据库中则表现为Post表持有一个userNo字段。
关联表映射
模式概要：把关联保存为一个表，带有指向表的外键。
项目实践：用户体系系统中“用户账户关系表”，作为值对象，持有userNo和accountNo。