实现领域驱动设计（1）

最新推荐文章于 2024-07-22 11:00:17 发布

hamish-wu

最新推荐文章于 2024-07-22 11:00:17 发布

阅读量256

点赞数

分类专栏：业务架构文章标签：领域驱动 DDD

本文链接：https://blog.csdn.net/keep_learn/article/details/104662866

版权

业务架构专栏收录该内容

4 篇文章 0 订阅

订阅专栏

很多因素会使软件开发复杂化，但是最根本的问题是问题领域本身错综复杂，如果你要为一家人员复杂的的企业提高自动化程度，那么你开发的软件将无法回避这种复杂性，你能所做的的只有控制这种复杂性。
控制复杂性的关键是有一个好的领域模型，这个模型不应该停留在领域表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需要的支持。

作为一个从业5年的程序员，经历的项目有大有小，总体趋势是软件系统越来越复杂，在典型的项目团队中，业务部门作为需求方，把自己的需要的功能点传递给产品部门，产品对开发提出需求，开发评审之后，测试上线发布。
现实中往往会遇到各种各样的问题，特别是新组建的团队，每个人都会有自己的工作模式，彼此沟通起来效率低下。

随着产品的迭代，项目会分模块甚至于拆分成微服务或者是独立的中台，新的功能提出来之后，涉及多个开发时，彼此往往达不成一致，到底这个新的功能应该放在哪里，有谁负责。
长此以往，项目便会逐渐失控，项目的逻辑和设计随着一次次新需求被破坏，知道项目无法维护重构。

有些项目领导会利用自己的经验，主导模块的划分，大部分情况下经验可以启动作用，可能需要团队程序花费时间适应领导的思路。但随着业务的发展，项目逐步复杂，直到经验无法起到作用。

领域驱动设计正是为了解决复杂的软件系统，经过多年实践，形成一套理论实践。

领域驱动设计20年前便出现，但没有广泛的应用，个人猜想原因如下：

学习成本高，领域驱动属于较高层次的技能，需要学习者有项目分析（业务架构）经验，UML建模经验对于专业领域熟悉
软件行业发展不成熟，大部门项目不够复杂，利用瀑布或者数据模型可以完成整体设计

领取驱动设计是解决复杂系统设计的利器，但对于比较简单的业务系统，领域驱动设计也可以帮助团队提高开发效率。

领域驱动设计简称DDD

Domain Driven Design

DDD不是意向技术，不同于java 或者python 或者sql
DDD并不能称之为技术，更多的算是技能，一套解决问题的方法，如果前面所说，对于简单的项目，瀑布模型或者快速原型模型也可以解决。
DDD可以简化设计，使得团队成员了解系统核心，从核心入手，简化初始设计，逐步迭代。

典型的开发模型有：
1.边做边改模型（Build-and-Fix Model)
2.瀑布模型（Waterfall Model)
3.快速原型模型（Rapid Prototype Model）；
4 . 增量模型（Incremental Model）；
5.螺旋模型（Spiral Model）；
6.演化模型(evolution model)；
7.喷泉模型(fountainmodel)；
8.智能模型(四代技术（4GL）)；
9.混合模型（hybrid model）；
10.RAD模型；

DDD具有很陡的学习曲线，一开始你可能从下手，我的建议：多思考，多交流

不建议没有软件开发经验的人学习，最好具备大型项目经验，这样结合你的经验能快速理解DDD如何解决你遇到的痛点。
建议有野心的产品同学学习一下，DDD并不是一门技术，学习过程不需要写代码。

即便没有掌握DDD,理解了DDD的思想也会对你的工作有很大帮助。

随着软件行业发展，或许会有更好的理论实践来解决我们工作中遇到的问题，但目前DDD对于复杂的业务系统是最有效的。

书中总结了DDD的价值：

1.你获得了一个非常有用的领域模型
2.你的业务得到了更准确的定义和理解
3.领域专家可以为软件设计作出贡献
4.更好的用户体验
5.更清晰的模型边界
6.更好的企业架构
7.敏捷、迭代式和持续建模
8.使用战略和战术新工具

《实现领域驱动设计》Page22

理解

领域模型可以理解为业务模型，这个模型可以长期适应业务的发展演变，模型可以掌握业务的发展，
理解业务更准确，领域专家一般属于业务人员，这里业务、产品、项目经历均可以成为领域专家，对于业务领域非常了解，这样配合系统给专业用户使用体验会更好，这点财务专业软件可能会更好体现。模型边界清楚之后各个模型职责清晰。领域模型可以推动企业架构的优化（这点不确定）对于软件的建模更加持续。