学习内容

本周学习内容，主要是架构设计的整体过程方法和这一过程中的标准工具UML。老师分享的经验非常贴近实际，属于较为经典的统一过程RUP的实践：用例驱动+架构导向+组件化。



内容总结

架构设计过程， 业务实际 -->用例分析(业务模型） --> 组件设计（概念模型） --> 类设计（设计模型）。通过这一过程，用例代表的现实业务过程，逐渐被组件、边界、实体、控制等软件领域的语言所描述、替代，从而完成设计过程。UML是上述设计过程的一个图形建模工具，用于记录思考和文档沟通。当然，UML与这个过程不是强绑定的，但它已经成为了这一个过程的最佳实践和描述标准。本周学习时，重点重新学习了用例驱动的过程，和各个阶段可用的UML图形工具。



思考：架构设计过程，用例驱动和领域驱动

目前，本人工作中，逐渐尝试使用领域驱动方法去建立业务到实现的映射。本周重新学习用例驱动后，思考了两者的区别，记之备忘：

1. 用例驱动和领域驱动都有领域模型，但用例驱动方法中，领域模型是从属的地位，它是由用例推导而产生的；而领域驱动模型方法中的领域模型则是核心，其他一切由它为基础来推导；

2. 用例驱动是由外而内，先招式后内功。设计从对系统的场景需求开始，定义出系统如何满足各场景下客户的价值诉求。这一过程，是外在的，有需求支撑。用例驱动的结果是我们的软件设计以实现一个个场景为目的，认为当一个系统的行为满足了所有客户的期望后，该系统就是一个成功的系统。业务架构建立在用例分析的基础上，它是在软件过程中扩展的，而不是基础。寻找这些业务运行规律，顶一个出一个通用的业务架构，则是随着多个项目的进步逐步形成的。用例驱动容易落地，有浓浓的使用主义思想；

3. 领域驱动是由内而外，先内功后招式。它要求对业务有较深的理解。团队要有业务专家的角色。业务专家到从业务领域里找到反映业务本质的实体、规则、交互机制，将他们抽象化。然后，再通过普通原理去实现具体的业务过程。它试图从根本上解决问题，让系统架构和业务架构保持一致，把业务管理化、标准化、抽象化，有了原理，以快速应对不同的场景

4. 就个人体会而言，在实际项目中完全运用领域模型非常困难。例如，战术设计时，你要非常了解业务，才能根据对象职责建立合适的实体对象、值对象和服务对象。在这里技术不是问题，业务才是。另外，领域模型虽然推崇迭代，但每次迭代，我们都要重新审视整个领域模型，必要时还的重构它，使它保持优美的对象模型。这种重构，要是发生在项目后期，则....。用例驱动，则可以暂时放弃复用要求，保持产品的交付。

5. 通过用例驱动保命，通过领域驱动沉淀产品