前面几篇文章我们大部份都是在讨论 :

集中式架构如何的分层

但应该有不少人注意到，我们是专注在每一层的『 技术 』分层该做什麽事情，要处理画面的就丢到 Presentation Layer，要处理业务逻辑的就丢到 Domain Layer，而要处理资料的就去 DataSource Layer，这个前期还可以，但过了一段时间就会变的如下图一样，每一层都非常的肥大，尤其是新创企业前期为了追求快速。

基本上会面临的问题为 :

• 可能一个 repository ( 放程序码的地方 )，有 5 个团队一起在使用，每天解 conflict 就饱了。
• CI/CD 的时间拉的非常久。
• 有的团队的业务 QPS 就是很高，有的很小，这样整个扩展性会有问题，也会浪费不少钱。
• 多个团队有可能会有不同的撰写风格，有机率会进入混沌时代。
• QE 与 QA 测试难度增加，因为你想想假设 QE 在某个测式环境进行测试中，结果另一个团队又进程序码了，那 QE 基本上一定只能重测，因为不能保证进的不会影响；如果规定时间才能进，那代表整个 deploy 时间会变很长，因为要排队；开多个测试环境，但问题在於，一定要有个环境是测所有团队程序码合并後的地方。

所以之後就会往下图这个方向前进，也就是所谓的 :

微服务

困难点

要往微服务这个方向前进的人们，应该都有面临的到的问题那就是 :

怎麽切 ?

对 ~ 就是要怎麽切 ? 要用什麽单位来切 ? 那假设我们的 domain layer 都是混在一起，要怎麽办呢 ?

DDD Domain-Driven Design 的诞生

Eric Evans 在 2003 年发表了 Domain-Driven Design: Tackling Complexity in the Heart of Software 这本书，书中提出了 :

以业务视角出发，来建构出软件架构

那 DDD 和我们上面提到的难题有什麽关系呢 ?

DDD 就是可以帮助我们建立一个，好切的架构。

接下来会有几篇文章，我们会来讨论它的架构於 :

• 战略 : 如何切
• 战术 : DDD 分层架构

单体式如何到微服务

不过这里要说一下，如果你的最一开始就是以 DDD 来进行专案开发，那恭喜你，你们未来要切成微服务应该没有到太困难，但如果你们是很大包恶心的集中式要切微服务，呃…… 我现在还不知道怎麽解，因为我现在也碰到这个问题。

目前我们在看《单体式系统到微服务 (Monolith to Microservices)-Sam Newman 》这本书，书中有提到几个建议，我在这里记录一下 :

• 重新单体式系统 : 组织现有的整体架构，让未来好切分，书中强烈推荐《 Working Effectively with Legacy Code : 管理、修改、重构遗留程序码的艺术 (中文版) - Michael Feathers 》，其中『 缝隙 』的概念最重要，不过这本我没看过，所以不知道是啥。
• 模组化单体式 : 就是将一些东西 libary 化，作者认为这是最好的方法。但我自已觉得问题会与切微服务的问题一样，『 要以什麽单位来切 libary 呢 』?
• 渐进重写 : 作者倾向『 先挽救现有程序码 』然後再重新实现功能。然後他还发现很多团队会有新功能时就新创建微服务，但问题在於你新创建的微服务，能避免之前发生的问题吗 ?

这後有空在来开一篇，来写写书中里所提到的分割方法。

小总结

这篇文章简单的谈谈，我们之前的 3-Tier 又可以称为集中式架构，所面临到最大的问题 :

太大了，不知道如何切，怎麽切都会有混在一起的业务逻辑

而 DDD 的诞生就是教我们如何设计出一个『 好切的架构 』，但这不代表我们前面提到的那些都不重要，因为那些东西的概念仍然会在 DDD 里面有使用到。

软件架构也是有一张地图。

接下来我们将会开始往 DDD 研究。