[DAY6] 万事起头难

找救援

意识到有问题时，首先寻找有没有专案遇到同样的问题——有使用 Ruby on Rails 的大规模专案不少，那为何不会浮现这些问题，代表我们肯定是有哪个环节需要修正，但每个专案的情境和需求都大相迳庭，因此没有甚麽进展。

因缘际会下，同事麦可认识了领域驱动开发(Domain-Driven Design，後简称 DDD)，并认为我们可以试着遵循里面的原则套用在专案，理由有以下几点:

• 领域知识庞大，细节众多
  单独一人几乎不可能掌握领域中所有的细节，而 DDD 可以专注在业务逻辑，并让程序码更容易被测试，使开发人员可以在短时间透过测试了解领域知识。
• 需求一直在变
  DDD 可以让程序更好的模组化，而更好的模组化代表开发时更弹性，有效应付持续变动的需求。
• 领域知识复杂
  透过 DDD 的战略设计可以使业务人员更好地理解自己的需求，并让开发人员与业务人员有效的沟通，避免鸡同鸭讲。

决定要导入 DDD 後，首先是先整理目前的状况

第一步

一开始我们先做了两件事

• 分析现有系统，并尝试切割出不同领域
  我们先印出 DB 中的 er-diagram 和列出网站大致上的所有功能，接着尝试把我们认为是同一个领域的 model 圈在一起，其中也会有出现不同领域共用同一个 model 的情况。

• 在核心领域(core domain)中找寻共通语言与领域事件
  透过目前的程序码和到处询问相关部门的人员，收敛领域知识。这边比较有系统的做法可以透过 事件风暴 (Event storming) 的方式来实践。

  关於事件风暴可以看这系列的文章，有详细的解释
  Event Storming Part 1 - 简介与事前准备

Q: 要怎麽知道这样切割的领域是对的?

专案一开始如果视为一个大领域，不管怎麽切都可以减少需要关注的逻辑，因此对我们来说这样的改动方向是对的。
当时我们的想法是，先透过既有程序码和脑中旧有的知识大致规划出一个雏形，这样的切法肯定不会是最完美的，但至少能降低每个领域的复杂度，收敛各领域的知识并为其建立知识库和测试，而有了测试，要再把领域切更细或是把多个领域合并成一个都会比较轻松。
除此之外，每个领域的设计其实会对应到我们对该领域的认识，而切分领域会使我们更专注在业务逻辑上，这也使我们更容易对领域去做更深的认识。
我认为切割领域是一种持续循环的调整，因此只需要满足当前的需求就可以有效地解决问题，当新需求进来时，如果目前的设计导致开发成本过高，代表有新的领域知识，需要重新调整领域。

後记

一开始踏入 DDD 是透过阅读 Eric Evans 所撰写的领域驱动设计，老实说到现在仍有许多地方没有理解的很透彻，直接阅读本书会有许多新的观点，但比较可惜的是这本书对如何实作 DDD 的方法着墨较少，所以後来都把这本书当作灵感书来使用，当有想不通的地方回去翻翻通常都会有新发现。