DDD第1篇 - 为什么使用DDD？
点击上方“xy的技术圈”，选择“设为星标”
认真写文章，用心做分享。
微信公众号：xy的技术圈
个人网站：yasinshaw.com
正文
先说声抱歉，最近两三个星期都没有产出新的文章了。一方面是忙(懒)；另一方面是在想能写什么题材，毕竟日常开发中遇到能写的问题其实不多。
恰好最近参加了公司的DDD（领域驱动设计）培训，再加上自己目前项目上也是使用的DDD，半年来大家也遇到过一些坑。所以打算写一些DDD方面的文章，算是对知识的提炼、总结。
DDD为什么火了？
第一次听到DDD这个词是在几年前。乍一听感觉像TDD（测试驱动开发），但其实它们完全是两回事。当时看了一篇介绍DDD的博客，一大篇专业术语，搞得云里雾里，便没有深究下去了。
虽然DDD早在2003年就提出了，但一直没有火起来。直到最近两年才慢慢被大家熟知。深究其原因，我觉得有三方面：
第一方面，DDD是解决复杂软件问题的，而之前的软件大多没有很复杂的逻辑，不用DDD也能玩得转；
第二方面，DDD一直没有很好的落地指导，一直到《实现领域驱动设计》这本书的问世，为DDD的落地打开了大门；
第三方面，国内没有团队去研究和布道，所以导致了解它的人本就不多。
后来微服务大火以后，发现使用微服务有个痛点，就是如何去设计和拆分微服务。而DDD可以很好地解决这个问题，所以DDD乘着微服务的东风，也变得慢慢被大众熟知。
DDD到底是什么鬼？
DDD是当今业界唯一一个包含了从需求分析到落地的工具。DDD将重心放在业务上，从业务出发来设计代码，业务是DDD的中心。
DDD分为战略部分和战术部分，两者相辅相成。战略部分用于理解、梳理业务，找到核心业务，更好地划分系统（这也是DDD为什么可以用于指导微服务设计的原因）；战术部分用于落地到代码上，用代码来清晰地表示业务，代码如何分层、如何设计都有一套成熟的指导方案。
DDD可以比较好地解决复杂业务的软件开发，但DDD不是“银弹”，DDD也并不是一些死板的术语和规范。事实上，当今业界仍然在DDD的实践道路上探索前行。
银弹：某种便捷的开发技术，从而使某个项目的实施提高效率。
DDD同样不是唯一的选择，只是可以作为众多工具箱中的一个，在衡量成本和收益之后，可以取出来结合其它工具一起使用，为自己的业务服务，为自己设计更好的软件服务。
所以“领域”到底是什么？
所以“领域驱动设计”这句话后两个词很好理解，但“领域”到底指的是什么？
DDD通过分析业务，最终构建成一个个“领域”，设计出一个个富含业务行为的、饱满的“领域模型”。
在DDD里，“领域”指的就是一块业务范围。比如在一个电商系统中，可能会有“商品领域”、“订单领域”、“物流领域”、“仓储领域”等等。DDD通过战略部分指导我们根据业务划分出业务领域，并区别出哪些是核心领域，哪些是支撑领域和通用领域。这个我们会在本系列后面的文章中详细解释。
“领域模型”指的是业务的载体对象，比如“商品”、“订单”等等。这些对象具有一些有业务含义的方法，比如“商品.加入购物车”方法。我们把主要的业务逻辑内聚在领域对象里，这样一个操作要做的事情就变得非常清晰，并且易于维护。
简单来说，“领域”和“领域模型”能够更直观地表现业务，把业务真正落地到系统架构和代码设计上。
为什么需要DDD？
“即使我们的软件中没有bug，也不能表示我们设计的软件模型本身就是好的”。使用DDD，能够让我们的软件设计更加合理，但不止于此。
对于一个业务复杂的系统而言，使用DDD有如下好处：
开发者和熟悉业务的人一起工作，加强团队间不同角色的合作；
能够帮助业务人员和开发人员梳理清楚复杂的业务规则；
开发出来的软件是能够准确表达业务规则的，设计就是代码，代码就是设计；
什么时候需要使用DDD？
使用DDD是有一些成本的，你的团队成员需要去了解DDD的一些基础知识，最好还需要有人做过DDD方面的实践，有一定的经验。
做任何事情都需要衡量成本和收益，技术方案的选型也不例外。DDD有一定的成本，但也能带给我们显而易见的收益。
一般来说，DDD适用于“业务复杂”的且“需要维护和扩展”的系统。
首先，我们来看看什么叫业务复杂。试想一下，如果你的系统只需要对几个简单的表进行CRUD，那你不需要使用DDD，甚至都不需要开发一个应用程序，直接使用一个数据库客户端可能就能解决问题。
从经验上来看，如果你的系统有30个以内的业务操作或用户故事，那也是没有太大必要去使用DDD的。而如果超过三四十个，软件就会有一定的复杂性，这个时候就可以考虑使用DDD了。
另一方面来说，即使现在这个软件并不复杂，但后续会进行开发和扩展，在可以预见的将来，它会变得复杂，那也可以考虑使用DDD。而一些初创公司，它们或许只需要一个简单的产品来快速测试市场反馈，后续并不会继续开发和维护，而是考虑重新购买或者从头开发的话，那也没有必要浪费成本去使用DDD。
所以再次总结我们什么时候需要使用DDD呢？业务复杂且需要长期维护的时候。
什么是DDD-Lite？
在了解DDD的过程中，你或许会听到DDD-Lite这个词。它是什么呢？它是DDD吗？
DDD-Lite简单来讲是DDD战术模式的一个子集，它更多的是关于技术实现层面，往往忽略了DDD的战略部分。但它并不能称为DDD，因为战略模式在DDD是非常重要的。DDD既需要战术模式来实现，也需要战略模式来指导，缺少了哪一部分，DDD都不是完整的。
如果单使用DDD，可能并不能完全地表现业务，并且可能导致劣质的领域对象。因为缺少了DDD战略模式中的“通用语言”、“限界上下文”等工具来指导辅助。
总结
其实纵观全文，可以发现DDD的核心就是一个词：业务。DDD的一切工具、实现都是以业务为中心，从业务展开的。所以如果要想实施好DDD，一定要认清业务的价值，关注业务，理解业务。
敬请期待：
《DDD第2篇 - 子域与限界上下文》
END
推荐阅读
MySQL查询优化
MySQL索引原理
MySQL索引使用策略和优化
Mysql的并发控制原理
Java直接内存的分配和释放
↓↓↓ 点击"阅读原文" 去【评论】吧