读张逸的领域驱动设计笔记 原
领域驱动设计可能会给你带来的收获，下面几点来自于原文，建议读者阅读原文:
- 领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。
- 领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。
- 领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。
- 领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。
- 领域驱动设计的思想、原则与模式有助于提高团队成员的面向对象设计能力与架构设计能力。
- 领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。
领域驱动设计(Domain Driven Design,DDD)是Eric Evans提出的综合软件系统分析和设计的面向对象建模方法。它改变了传统软件开发工程师针对数据库进行的建模方法，从而将要解决的业务概念和业务规则转换为软件系统中的类型一级类型的属性与行为，通过合理运用面向对象的封装、继承和多态等设计要素。仔细想想，我们在开发项目时，是不是只是思考数据库的设计，围绕着数据库进行各种操作的呢！
领域驱动设计是一套方法论，它建立了以领域为核心驱动力的设计体系，具有一定的开放性。领域驱动设计强调领域模型的重要性，并通过模型驱动设计来保障领域模型与程序设计的一致。所以一定要甄别出领域模型？
领域驱动设计贯穿了整个软件开发的生命周期，包括对需求的分析、建模、架构、设计，甚至最终的编码实现，乃至对编码的测试与重构，真是这样?
领域驱动设计围绕着领域模型进行设计，通过分层架构(Layered Architecture)将领域独立出来。表示领域模型的对象包括：实体、值对象和领域服务，领域逻辑都应该封装在这些对象中。领域逻辑都封装在这些对象中？这是不是意味着富血模型。这样严格的设计原则可以避免业务逻辑渗透到领域层之外，导致技术实现与业务路基的混淆。
战略设计会控制和分解战术设计的边界与粒度，战术设计则以实证角度验证领域模型的有效性、完整性、一致性，进而以演进的方式对之前的战略设计阶段进行迭代，从而形成一种螺旋式上升的迭代设计过程。
面对客户的业务需求，由领域专家与开发团队展开充分的交流，经过需求分析与知识提炼，以获得清晰的问题域。难点在于需求分析、知识提炼。辅以分层架构与六边形架构划分系统的逻辑边界与物理边界，界定领域与技术之间的界限。之后进入战术设计阶段，深入到限界上下文内对领域进行建模，并以领域模型指导程序设计与编码实现。若在实现过程中，发现领域模型存在重复、错位或缺失时，再进而对已有模型进行重构，甚至重新划分限界上下文。
通过对问题域进行分析和建模，识别限界上下文，利用它划分相对独立的领域，再通过上下文映射建立它们之间的关系，
学会对设计的本质思考，不要只限于设计概念的掌握，要追求对设计原则与方法的融汇贯通。
软件复杂度的成因
- 理解力：软件系统的规模、结构
- 预测能力：变化
控制软件复杂度的原则
导致软件复杂度的成因是规模、结构、变化三要素，要控制复杂度，就需要对他们进行各个击破。
- 分而治之、控制规模，一定要拆为小的。
- 保持结构的清晰与一致
- 拥抱变化
可进化性、可拓展性、可定制性。
可进化性：可划分设计单元的边界，确定各个设计单元应该履行的职责以及需要与其他设计单元协作的接口。由于每个单元有自己的边界，边界内的实现细节不会影响到外部的其它单元，所以，我们很容易的替换单元内部的细节，保证他们的可进化性。
可拓展性：首先要识别软件系统的变化点，常见的变化点包括业务规则、算法策略、外部服务、协议标准、数据格式、业务流程、系统配置等。处理这些变化点的核心就是"封装"，通过隐藏细节、引入间接等方式来隔离变化、降低耦合。
可定制型：感觉可定制性与可拓展性有点类似。
有些地方，还不理解，更新中......
(adsbygoogle = window.adsbygoogle || []).push({});