学习《领域驱动设计-软件核心复杂性应对之道》的过程随笔《第一章》
本随笔谨用于记录本人学习《领域驱动设计-软件核心复杂性应对之道》的过程和收获，愿与大家共享之
初写于2024.07.24，学习未竟，随笔伴行--
本人于工作期间阅读该书，发现很多值得反复学习的方法和思考方式，随笔记录；
兴之所至，兴尽即止---
本文是针对面向对象开发人员所编写的，如不合适，请自行斟酌是否继续阅读---
接下来正文开始：
前言
作者结合自己的开发经验，在书中为作出设计决策提供了一个框架，并为讨论领域设计提供了一个技术词汇库
本书讨论的前提是：
1.大多数项目中，主要的焦点应该是领域和领域逻辑；ps:所谓领域和领域逻辑即项目完成后落地实施时所面向的人群标签，所涉及的人群标签，设备和物流等物理和非物理的实体和概念性实体等以及它们之间的数据流转方向和方式等；
2.复杂的领域设计应该是基于模型；ps：MBD允许客户和工程师模拟和验证在开发早期的设计，即通过早期先设计业务流程的方式？在设计初期确定好业务的流程，至少是大概流程，后续基于此流程进行软件的开发；
其次，本书主要是面向“敏捷开发过程”这一新体系：
敏捷开发是一种基于迭代开发的新的开发体系；它倡导极限编程，反对预先设计。尽管体系承认设计决策对软件的重要性，但它更倾向于将精力投入到促进沟通和提高项目快速变更能力的工作中。
因此，在敏捷开发的过程中，开发人员至少更少的设计，每次只利用最简单但能实现目标的方案即可，并在后续的开发中进行不断的重构，最终得到满足客户真正需要的设计
（该思想类似于贪心算法，在每一步都寻求局部最优解，从而获取最终的全局最优解）
但是这样的开发体系也存在一些问题：
1.在寻求局部最优解的过程中，可能会导致最终结果偏离全局最优解，这是所有的贪心算法的通病；
2.敏捷开发的思想要求开发人员每次都使用最简单有效的方案来实现本次设计目标，这可能导致前期的设计不足会影响到后期开发的设计难度；
3.敏捷开发对软件开发人员的设计能力有一定的要求，需要开发人员具有敏锐的设计感和在设计中的缜密思考能力；
第一部分 运用领域模型
第一章 消化知识
软件的作用是为了满足业务的使用需求，其核心是帮助用户解决领域相关的问题；这意味着一个软件的设计不应该围绕软件本身，而是要围绕着解决领域中的问题为核心，并且以提升客户的使用体验为宗旨对软件进行优化和改进
1.有效建模的要素：
（1）模型和实现之间的绑定；软件的作用是为了满足业务的需求，所以软件和业务之间是存在天然的联系的，沟通过程中的模型和模型的实现也是存在天然的联系的，沟通和迭代应该是基于他们之间的这种联系的；
（2）建立了一种基于模型的语言；一种基于模型的语言，而不是简单的通过日常语言来沟通。语言是沟通的重要工具，合适的工具能够大幅提升工作效率，沟通也一样，尤其是在软件设计领域的沟通中，使用基于模型的语言既能保证沟通的效率也能保证所有的沟通都是基于模型和实现的绑定关系进行的；
（3）开发一个蕴含丰富知识的模型；对象具有行为和强制性规则，模型不仅仅是一种数据模式，它还是解决复杂问题的不可或缺的部分，其包含各种类型的知识；
（4）提炼模型；在模型被持续迭代优化的过程中，其核心的属性和动作应该被保持，一些一开始觉得重要但后续觉得不重要的信息应该被移除；
（5）头脑风暴和实验；不存在所谓的“灵光一闪”，所有的灵感都来源于丰厚的积累，所谓的灵感只是在无数个不好的方案被废弃掉后终于被通过的普通的念头；
2.知识消化
没时间写了，先下班，后面再补....
续写：
（1）知识消化一般是在开发人员的领导下，由开发人员和领域专家组成的团队共同协作；（而整体项目的推进个人来看应该与之相反，应该由领域专家带领开发人员开进行整体上和细节上的设计和开发）
（2）在瀑布模式中：业务专家与分析员(需求管理一类的角色)进行沟通，然后程序员和需求管理员进行沟通详细需求并开发，这种方式中知识的流动是单向的，而且不会累积（除非你主动学习记录）；
（3）在迭代模式中，开发人员依然是根据业务专家的描述来构建整个功能体系，并在此基础上进行扩展。一名优秀的程序员会自然的抽象出一个具有更高的可扩展性的模型，但如果这个过程如果缺少业务的帮助，很容易得到一个幼稚的模型；
（4）模型聚焦于需求分析，通过良性循环加深团队成员对领域的理解，是一个不断演化的过程。
3.持续学习
当我们开始编写软件的初期，我们所知的信息与完成整个项目所需要的全部知识相比具有很大的差距。
项目知识往往分散在很多人，设备，文档中，其中夹杂着一些无关信息。这种无知往往会导致我们在开发初期对项目的难度产生很大的误判；
同时，所有的项目都存在知识的丢失。因此一个团队需要有意识的积累知识，并且保持持续学习。
4.知识丰富的设计
业务活动和规则与所涉及的实体，都是领域的核心
知识消化所产生的模型能够反映出对知识的深层理解，因此在模型发生改变的同时，开发人员需要对实现进行重构，从而反映出模型的变化。
当建模不再局限于寻找实体和值对象时，知识才能够被充分吸收。（要理解领域中的业务活动和规则的底层逻辑，而不是只做简单的增删改查）
5.深层模型
随着对领域和需求的理解加深，最初的模型元素可能会被丢弃，或者改变角度。
知识消化是一种探索，它永无止境。
