闲聊DDD

DDD，领域驱动设计的英文简称，其核心就是要解决软件的复杂度问题。

软件是技术与业务的结合体，两者缺一不可。因此，软件复杂度必然是伴随技术复杂度和业务复杂度而产生的。技术实现的复杂性和业务规则的复杂性揉合在一起，就像面团中的面和水彼此相容，这也造成问题的千头万绪，往往是解决了技术问题又削弱了业务功能；满足了业务功能，又带来技术实现的复杂度，鱼和熊掌不可以兼得也。

DDD的解决之道就是，拆分复杂度，分而治之。拆分技术和业务的重要方法就是分层，一个典型的WEB应用会被拆分成视图层、应用层、领域层、数据访问层以及其他层次等，各个层次专注于本身的职责，减少混在一起带来的复杂度，而DDD的核心任务就是解决领域层的复杂度。

比如说要实现一个导出财务数据的EXCEL功能，我们可以考虑把这个功能拆分成两方面来考虑：第一，EXCEL导出功能（技术）；第二，财务数据的提取和编排要求（业务）。拆分之后，分别进行设计和实现，然后通过应用层实现两者的交互。通过这种分层设计，可以有效地把各自己的功能特性隔离开来，避免相互影响。

领域建模，DDD的核心，也是最难把握的一部分。如果要完全掌握，必然要学习面向对象相关的理论，设计模式，领域知识，建模方法和工具等等。当然，纸上得来终觉浅，我们还必须通过大量的实际操作才能体会个中的奥妙。

虽然建模与否，都可以写出代码，都可以实现功能。短期来看两者贡献的价值都是一样的，但是随着软件规模的扩大，业务规则的复杂度的上升，我们就能体会到建模与不建模，建模好与坏的区别。

最后想说，好的软件都是设计出来的，是一件艺术品。