逻辑架构设计

逻辑架构的输入是用户需求，输出是“我们的系统到底为哪些用户提供什么样的功能”。

用例模型分析

在逻辑架构设计过程中，通过用例模型分析这个系统到底要做什么功能？ 用例模型：是一套基于UML用例图进行需求分析的实践方法，它将要分析的业务系统当成一个黑盒，描述了系统到底为用户提供了哪些功能。一般来说，一个用例模型中通常有三个元素：用例（User Case）,参与者（Actor），系统边界（Boundary）。

用例与用例之间有3种关系：包含，扩展，继承
包含：就是将该用例中业务流程的某些相对独立的环节单独提取出来做成的用例，是原有用例的一部分，又叫子用例。
扩展：就是在原有用例的基础上，在业务流程中的某个扩展点去扩展某些新功能。
继承：体现的是一种父子关系。

领域模型分析

当我们实现新需求时，应当采用“两顶帽子”的方式进行设计，这种方式要求在每次变更时将变更分为两个步骤：

• 在不添加新功能的前提下，重构代码，调整原有程序结构，以适应新功能
• 实现新的功能 过去我们每次软件设计时总是担心日后的变更，就设计了很多所谓的“灵活设计”。然而这种往往没有达到预期的效果，导致我们的架构过度设计。有了“两顶帽子”，我们就再也不担心过度设计了，正确的思路应当是“活在今天的格子里做今天的事情”。也就是只为当前需求设计，使其刚刚满足当前的需求。所谓的“高质量的软件设计”就是掌握一种平衡，既可以满足当前的需求，又能让设计刚刚满足需求，从而使设计最简化。

什么是领域设计？

软件的本质就是对真实世界的模拟，真实世界是什么样子，软件世界就是怎么设计，这样日后不论什么变更，都按照这样的方法进行设计，就不会迷失方向，设计质量就可以得到保证，这就是领域驱动设计（Domain-Driven Design， DDD）的思想。
领域驱动中我们常常会用到一些设计模式：

• 策略模式：
• 适配器模式：
  领域驱动设计的核心是统一语言，也就是我们去主动理解业务，理解约为流程和业务痛点，理解用户提出的业务需求背后的动机。

技术可行性分析

在逻辑架构的设计阶段，我们对即将设计的软件系统进行需求分析，这个阶段的输入是用户需求，输出是软件最终要为用户提供哪些功能，我们需要站在专业的软件设计角度去思考问题：

• 跳出需求去分析需求相关的业务。 有经验的架构师在与用户探讨需求时，起初不谈当前的需求，而是与用户探讨相关的业务场景，包括业务流程，业务规划，业务痛点等等，把这些理解清楚了再返回到业务需求上，我们才能够深刻理解用户为什么提出这样的需求
• 分析需求背后的动机。
• 基于需求动机去制定可行的方案