很多因素会使软件开发复杂化,但是最根本的问题是问题领域本身错综复杂,如果你要为一家人员复杂的的企业提高自动化程度,那么你开发的软件将无法回避这种复杂性,你能所做的的只有控制这种复杂性。
控制复杂性的关键是有一个好的领域模型,这个模型不应该停留在领域表面,而是要透过表象抓住领域的实质结构,从而为软件开发人员提供他们所需要的支持。
作为一个从业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
理解
领域模型可以理解为业务模型,这个模型可以长期适应业务的发展演变,模型可以掌握业务的发展,
理解业务更准确,领域专家一般属于业务人员,这里业务、产品、项目经历均可以成为领域专家,对于业务领域非常了解,这样配合系统给专业用户使用体验会更好,这点财务专业软件可能会更好体现。模型边界清楚之后各个模型职责清晰。领域模型可以推动企业架构的优化(这点不确定) 对于软件的建模更加持续。
实践领域驱动的困难:
1.身边缺少DDD的掌握者
2.领导不认同
3.缺少交流
其实大公司随着业务的复杂,很多都在实践领域驱动,如:ali 、美丽联合
听闻某厂P7要求必须掌握DDD
新手可以先掌握UML
学习DDD的必备基础,设置构建自己负责的模块领域模型图
利用互联网论坛等形式交流
DDD可以将团队成员汇集在一起,DDD并不需要高深的计算机知识,更多的是对业务的掌握。
DDD可以使得软件设计具有良好的伸缩性,配合企业战略预留设计余地,具备长远的规划。
有效避免了项目迭代后期的失控,我想大部门程序喜欢新起的项目,对于接收旧项目或多或少的头痛。
学习DDD
推荐两本书籍:
《领域驱动设计-软件核心复杂性应对之道》
《实现领域驱动设计》
接下来我的博客也会根据这两本书的理论和个人实践完成。
才疏学浅,疏漏错误敬请高手指正。
再谈失血模型
这里失血模型指的是 领域对象中几乎没有业务逻辑,只有get 或者set 方法
这本书出版时间2013年,结合目前市场上用mybatis 实践,项目中大部分业务逻辑代码都保存在service 层里
业务领域模型一般也映射到service 层里
这里 需要思考一个问题,业务逻辑的复用和粒度直接的平衡,如果一个service 某个方法里包含复杂的业务逻辑,那么被复用的场景微乎其微,如果只是简单的增删改查,那么很容易被其他领域复用。