如果你有以下的疑问，那你可以试试领域驱动设计。
当朋友和你聊项目时，你能否一语中的，说清你在开发中的业务内容及其价值？
当产品和你聊需求时，是否遇到过反复沟通之后才发现讲的不是同个东西的情况？
当你在做需求评估时，是否经常发现一个小的需求改动，总是牵一发动全身？
当你看产品文档时，是否经常发现代码很多逻辑文档里没更新进去？
当你接手前任的项目，是否要花很大的精力去熟悉散乱的代码，经历修改他人代码的痛苦？
当项目维护周期很长时，是否发现维护成本越来越高，经常想推倒重来？
出现上面问题主要的原因是，业务系统会慢慢变得复杂，为什么呢？
常见的情况是，业务在发展过程中为了探寻发力点，需要不断地试错迭代，调整方向，而系统在设计之初，难以预期到后面的瞬息万变，为了应付业务，修修改改，久之，系统也变得复杂起来。
可以怎么办呢？及时重构呗——不改变软件系统外部行为的前提下，改善它的内部结构。
然而重构是从技术层面上抽炼出来的模型，往往不具有实际的业务含义，其他同学可能难以自然地将业务问题映射到对应的设计模型。另外，如果不能如实映射业务模型，随着业务方向调整，代码可能又开始腐败……有点像芝诺悖论中，阿基里斯永远追不上小乌龟。
那DDD怎么搞？
DDD是这么想的：”将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构”。可能大家平时有这样的想法，但是比较模糊，未形成体系，而DDD就提供了一套完整的方法论。从业务角度去审视我们的系统，从而实现高内聚低耦合的代码。
整体而言，领域驱动设计包括战略建模和战术建模: 战略设计侧重于高层次、宏观上去划分和集成限界上下文，而战术设计则关注更具体使用建模工具来细化上下文。
DDD有哪些优势
接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。 DDD 是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的标准设计过程，使得你的设计思路能够更加清晰，设计过程更加规范。 DDD 善于处理与领域相关的拥有高复杂度业务的产品开发，通过它可以建立一个核心而稳定的领域模型，有利于领域知识的传递与传承。 DDD 强调团队与领域专家的合作，能够帮助你的团队建立一个沟通良好的氛围，构建一致的架构体系。 使用DDD可以降低服务的耦合性，让系统设计更加规范，即使是刚加入团队的新人也可以根据业务快速找到对应的代码模块，降低维护成本。 DDD可以用领域模型界限上下文边界快速拆分微服务，实现系统架构适应业务的快速变化，例如：系统的用户量并发量增长得很快，单体应用很快就支持不了，如果我们一开始就采用DDD领域驱动设计，那我们就能很快的把服务拆分成多个微服务，以适应快速增长的用户量。
关注“DDD落地”公众号，一起来学习DDD！
文章链接
您阅读本篇文章共花了：
发表评论