=======================================================================
              Software Engineering notebook

参考资料：
[1]:https://melsatar.blog/2018/02/16/the-waterfall-model-a-different-perspective/
[2]:Software Engineering Tenth Edition

对于软件工程而言，没有放之四海而皆准、适用于所有不同类型软件开发的过程模型。正确的过程取决于客户和管理需求、软件使用所处的环境，以及所开发的软件类型。

=======================================================================

瀑布模型是一个线性顺序流。在这个过程中，进展被看作是通过软件实现阶段稳定地向下流动(像瀑布一样)。这意味着开发过程中的任何阶段只有在前一个阶段完成时才会开始。瀑布方法没有定义返回到上一个阶段来处理需求变化的过程。

瀑布模型适合于不注重改变需求的项目，例如：
  1.由提案请求(RFP)发起的项目，客户有非常清晰的文档化需求
  2.关键任务项目，比如航天飞机
  3.嵌入式系统。

下面是使用瀑布模型时需要考虑的事项:

• 项目要求是明确的和固定的。
• 工程团队对于在不同项目中所使用的技术有清晰的认识。
• 项目不能以迭代的方式交付。
• 文档是至关重要的。
• 专业的项目管理技能。
• 项目成本已定。

waterfall model的优缺点：

原文作者：Mohamed Sami，将waterfall model称为SDLC模型之父，不是因为它是第一次引入的，而是因为所有其他模型都是基于瀑布模型进行设计而设计的，以增强其功能并消除其不足，从而确保更好的交付。

Mohamed Sami认为瀑布模型的主要缺陷是，它关注的是项目实现，而不是客户，不能实现对客户的快速业务价值。客户应该等待整个生命周期看到结果，这可能是好事，也可能是灾难。我认为我们不需要在开发生命周期的不同角度上达到上面图片中描述的困境，这就是为什么选择合适的模型对于能够根据需要交付预期的业务价值是非常重要的。

DDD（Domain Driving Design）领域驱动开发

1、微服务设计为什么选择DDD

1、架构对比

• 单机架构：数据驱动架构

• 集中式架构：面向对象的方式（三层架构）

• 分布式微服务架构：应用之间解藕，解决单体用扩展性和弹性伸缩能力不足问题

2、微服务的问题

• 微服务粒度

• 怎样拆分

• 边界是什么

DDD 核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。

3、战略设计（业务层面-业务架构）

建立领域模型、划分领域边界，从业务的视角来划分微服务边界（收敛的过程）

• 实体
• 命令
• 事件

领域模型：指导微服务的设计和拆分。事件风暴是建立领域模型的主要的方法，

事件风暴：

• 从发散到收敛的一整个过程
• 采用方法：用例分析、场景分析、用户旅程分析
• 产出：产出实体、命令、事件等领域对象，将领域对象从不同维度进行聚类形成聚合、限界上下文等边界，建立领域模型

逻辑边界、物理边界

4、战术设计（技术层面-系统架构）：

侧重于领域模型的实现，侧重于代码逻辑的设计和实现

实现层面

• 逻辑边界
• 物理边界

5、DDD和微服务

DDD：主要关注从业务领域视角划分领域边界，通过业务抽象建立领域模型，维持业务和代码层面的一致性

微服务：主要是从技术层面，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署

总结：DDD是一种架构设计方法，微服务是一种架构风格。DDD是一种从业务视角去分离系统建设复杂度的手段，应用于微服务中，DDD解决微服务设计过程中边界难以界定的问题。

2、领域、子域、核心域、通用域、支撑域

• 领域：指一种特定的范围。用于限制业务边界和范围的。

• 子域：对应更小的业务范围

  • 核心域：决定产品和公司核心竞争力的子域，业务成功的主要因素和公司的核心竞争力
  • 通用域：需要用到的通用系统
  • 支撑域：具有企业特性，但不具有通用性

复杂问题拆解细分，建立子域

• 研究对象
• 研究对象细分

领域的核心思想就是将问题域逐级细分，来降低业务理解和系统实现的复杂度。通过领域细分，逐步缩小微服务需要解决的问题域，构建合适的领域模型，而领域模型映射成系统就是微服务了。通过领域划分，区分不同子域在公司内的不同功能属性和重要性（核心域、通用域、支撑域），从而公司可对不同子域采取不同的资源投入和建设策略

3、限界上下文

• 通用语言定义上下文含义，限界上下文则定义领域边界

• 限界上下文就是用来细分领域，从而定义通用语言所在的边界

• 一个限界上下文理论上就可以设计为一个微服务

4、实体和值对象：从领域模型的基础单元看系统设计

DDD 引入值对象是希望实现从“数据建模为中心”向“领域建模为中心”转变。实体和值对象是微服务底层的最基础的对象。DDD 提倡从领域模型设计出发，而不是先设计数据模型。

实体对象（业务层面）

• 实体和值对象是组成领域模型的基础单元。

• 在代码模型中，实体的表现形式是实体类，这个类包含了实体的属性和方法

值对象（数据层面）

在领域建模时，我们可以将部分对象设计为值对象，保留对象的业务涵义，同时又减少了实体的数量；在数据建模时，我们可以将值对象嵌入实体，减少实体表的数量，简化数据库设计。

实体对象VS值对象

• 实体一般对应业务对象，它具有业务属性和业务行为；而值对象主要是属性集合，对实体的状态和特征进行描述。

总结：值对象的引入，保留了业务层面的含义，减少了实体数量，并且在数据建模层面，简化了数据库设计

5、怎样设计聚合？聚合和聚合根

• 聚合就是由业务和逻辑紧密关联的实体和值对象组合而成的，聚合是数据修改和持久化的基本单元，每一个聚合对应一个仓储，实现数据的持久化。

• 聚合在 DDD 分层架构里属于领域层，领域层包含了多个聚合，共同实现核心业务逻辑

聚合根解决了什么问题？

聚合根的主要目的是为了避免由于复杂数据模型缺少统一的业务规则控制，而导致聚合、实体之间数据不一致性的问题

聚合根承担的角色是什么？

如果把聚合比作组织，那聚合根就是这个组织的负责人。聚合根也称为根实体，它不仅是实体，还是聚合的管理者。

如何判断一个实体是否是聚合根?

可以结合以下场景分析：是否有独立的生命周期？是否有全局唯一 ID？是否可以创建或修改其它对象？是否有专门的模块来管这个实体？

6、领域事件

用来表示领域中发生的事件。一个领域事件将导致进一步的业务操作，在实现业务解耦的同时，还有助于形成完整的业务闭环。领域事件来驱动业务的流转

7、中台

敏捷中出现各种”XX驱动开发“的实践。起源主要是来自Kent在极限编程中提出的测试优先编程（Test-First Programming）。现在出现了（除了行为驱动开发以为，相关的还有像实例驱动开发（EDD-Example Driven Development），特性驱动开发（FDD-Feature Driven Development）等。

各种驱动开发之间的关系众说纷纭这里我们来聊一聊测试驱动开发（TDD）、验收测试驱动开发（ATDD）和行为驱动开发（BDD）。

测试驱动开发

Kent Beck最早在其极限编程（XP）方法论中，向大家推荐“测试驱动”这一最佳实践，还专门撰写了《测试驱动开发》一书，详细说明如何实现。

测试驱动开发（TDD）使用自动化测试用例来指导开发代码。TDD 过程包含下列活动：

• 新增一个测试（成生测试用例并自动化），用于描述在代码内的某一小片段所期望的功能（程序设计的思路）；
• 此时因为相应的业务代码还没有编写，测试无法通过；
• 编写业务代码并运行测试直到测试通过；
• 在测试通过后，如果代码又有变更，例如对业务代码进行重构，则需再次运行测试以确保变更后的代码仍然可以通过测试；
• 对代码内的下一小片段继续执行上述过程，需要运行之前的测试（回归测试）以及新加入的测试。

行为驱动开发和测试驱动开发介绍: https://www.itsource.cn/web/news/1933.html

虽然“测试驱动开发”里面有测试的字眼，但是这个其实还是个开发活动，通常都不是由测试人员负责的，即使其中的驱动开发的测试的代码也不是测试人员编写的，至于里面涉及到的代码的重构这些内容，就更是开发人员而不是测试人员编写的。

狭义的测试驱动开发一般指的就是单元测试级别的测试驱动开发。但是广义的测试驱动开发不仅仅可以用于单元测试级别，还可以用于集成测试或者系统测试级别。当然也可以用于验收测试级别，此时就是后面要讲的验收测试驱动开发。

敏捷中很多思想都是建立在个人或者团队能力成熟度很高的基础上的。很多团队在实施测试驱动开发的时候无法顺利的进行下去，有很大一方面是实施的团队的技能还没有跟上。你很难想象一个开发团队，在单元测试都无法高质量的完成的情况下，转型采用TDD能够成功。

验收测试驱动开发

验收测试驱动开发（ATDD），在用户故事的创建阶段就定义验收准则及其相关的测试。ATDD 强调协作，各个利益相关者（开发、测试、业务代表等）不仅要理解软件组件应该有何种行为，还要理解如何做才能确保可以通过验收。

验收测试驱动开发是一种测试优先的方法。

首先需要再实施用户故事之前创建测试用例。测试用例由包括开发人员、测试人员和业务代表在内的敏捷团队创建，可以是手工测试用例也可以是自动化测试用例。第一步是开展一个由开发人员、测试人员和业务代表一起参与分析、讨论和撰写的规格说明研讨会。任何在用户故事中不完整、不清楚或者错误的地方都会在这个过程中得到修复。

下一步是创建测试。这一活动可以由团队一起完成或者由测试人员单独完成。在任何情况下，测试都应该由一个独立的个人（如业务代表）来确认。这里的测试是描述用户故事中特性的例子。这些例子会帮助团队正确地实施用户故事。由于例子和测试是相同的，二者经常可以互换使用。这项工作从基本的例子和开放的问题开始。

一般而言第一次测试都是正向测试，在没有意外或错误条件下确认正确的行为，比较执行的活动的顺序，判断是否如期望的那样进行。在正向路径测试完成后，团队应该撰写逆向测试并且覆盖非功能属性（如性能，易用性）。测试须以利益相关者都能理解的方式表述，包含以自然语言表达的语句，这些语句应该包括必要的前提条件以及任何可能的输入和相关输出。

例子必须覆盖所有用户故事的特性，并且不应该添加新内容到用户故事中。这意味，不应存在那些描述没有被写在用户故事中的例子。另外，不应该有两个例子描述用户故事中的相同特性。

行为驱动开发

行为驱动开发（BDD）使开发人员聚焦于测试软件行为是否符合预期。由于测试是以软件行为的形式展示出来的，测试对于团队成员和其他利益相关者来说更容易。单从BDD的概念来说，它不仅仅是针对测试，它使得在业务团队和开发之间达成共识。在软件项目中涉及多人紧密协作，由产品业务讲解功能需求，开发负责代码实现，测试保证软件质量，高质量的沟通对项目成功至关重要。如果在一个项目中业务人员用自己行话，开发人员用技术语言、技术思维去理解业务，在沟通过程难免出现分歧，开发人员就可能按自己的理解去实现了一个错误的功能。

BDD用通用自然语言描述实例（系统行为）。团队成员使用统一、易读的语言明确实例，作为验收测试标准。一方面可以消除理解上的歧义，一方面可以激发思考没有考虑到的场景。这里的实例是可以随时运行，反馈系统运行真实结果，如果运行失败，要么文档过时需要更新，要么系统出现问题需要修复。

在讨论BDD和TDD、ATDD的关系时，有些地方把BDD看成一个新的完整的开发流程，也有些地方把BDD看成是TDD的延伸，ATDD的一种落地的实例。这只是从不同的角度来看待BDD，并不影响BDD的本质。

典型的 BDD 框架将验收准则用 given/when/then 的格式表示：

Given（给定）某些初始上下文，

When（当）一个事件发生，

Then（则）确保某些输出。

行为驱动开发，让开发做正确的事: https://yq.aliyun.com/articles/594347
行为驱动开发（BDD） - 一个快速的描述和示例： https://www.cnblogs.com/Javi/p/7158573.html
五分钟让你彻底了解TDD、ATDD、BDD&RBE： https://mp.weixin.qq.com/s/KCrkL4NeuZeZvTu5Sc6B_g

小结

TDD、ATDD和BDD通过在开发之前清晰的描述系统行为和开发详细的测试用例来帮助开发人员更好的开发出高质量的代码。 测试从以前的破坏性的方法转换到建设性的方法中来。 给整个开发带来的新的思想上的变化。但是这些新的思想在实践过程中的具体能够带来多大的好处，也受到使用的组织和人的各方面条件的限制。没有一劳永逸的技术，只有持续不断的改进。这才是敏捷思想的内涵。