写点什么

实战领域驱动设计开篇

作者:worry
  • 2022 年 2 月 11 日
  • 本文字数:1550 字

    阅读完需:约 5 分钟

实战领域驱动设计开篇

软件的核心是为用户解决业务相关问题的能力,除此之外所有的其他功能,不管它有多么的花哨,都要服务于这个基本目的。然而,面对纷繁复杂的业务问题,我们如何才能开发出高内聚、低耦合,富有有生命力的软件呢?要达到这个目的,我们首先就要将目光聚焦于业务。


然而,这些年随着互联网的发展,我们在不停学习别人的轮子,乐此不疲,乐在其中,我们喜欢干这样的事情,因为它更技术。拿我自己的从业经历来说,2006 年左右,面对的需求大多是 WEB 开发,接触了好多流行的框架:Struts1、Webwork、Struts2、Appfuse、freemaker 模版引擎、早期的 Spring Framework、Hibernate 等等。为了解决搜索问题学习了 Lucene、solr、ES,工具类的轮子接触的就更多了:apache commons、google guava、Dom4j、xstream、jackson、gson、apache poi、ehcache、quartz 等等。2010 年左右,由于大数据开发需求增多,我又开始接触 hadoop、flume、sqoop、ooize、pig、kafka、storm、spark、flink 等等大数据相关的框架。这些框架大多都有一个很吸引人的宣传语“使用我吧,让你把精力更多的用于业务”。我们不否认框架的积极作用,但是,我们真正用于考虑业务的时间有多少呢?


另一方面,从公司的组织架构上看,直接和业务交流的是产品经理,技术开发人员的需求是由产品经理整理转述而来的,开一次产品需求讨论会就直接让开发确定开发排期了,开发对于业务的理解是基于产品经理的总结,属于二手信息。这种分工进一步导致开发远离业务,沉静在学习轮子的乐趣中。这种分工也导致开发和产品之间矛盾冲突,网上的段子满天飞,现实中还有大动干戈,互相切磋武艺的。难道产品和技术不应该是亲如兄弟的关系吗?他们的目的都是为了解决业务需求啊。这样的分工起初开发的进度还能保证,但是随着业务的深入,开发人员就不得不进行大的架构调整,或者是充当“救火队员”,冲在故障一线,陷入 BUG 泥潭。究其原因还是由于对业务了解的太少了,初期模型出了问题,产品和开发没有基于业务模型的通用语言,沟通上存在鸿沟。


2011 年 4 月底,iPhone4 开始在中国内陆发售。移动互联网的用户增多,流量猛增,传统的单体架构受到了挑战,分布式的微服务架构开始被人们提及,如何将业务拆分为一个个的微服务成为人们讨论的重点?这个时候人们又想起了 2003 年 Eric 在《领域驱动设计》一书中所阐述的方法,领域驱动设计又重新进入人们的视野。领域驱动设计鼓励开发人员向领域专家、产品经理学习业务相关的领域知识,将领域知识浓缩为领域模型,以领域模型为核心和领域专家、产品经理共同建立通用语言,跨过沟通的鸿沟。领域驱动设计从战略和战术两个层面给我们提供了设计指南。战略层面,用子域去分离问题,将问题化为我们脑力可以轻松驾御的子域,将核心力量和精力放在核心子域上,其次才是支撑子域和通用子域。用限界上下文(Bounded Contexr)来解决问题,在限界上下文内部建立以领域模型为核心的通用语言,消除概念上的歧义。通过上下文映射图来理清组织关系和上下游的系统关系,让开发对项目有全局认识。战术层面,在限界上下文内通过实体、值对象、领域服务、领域事件来建立模型,通过模块来组织,通过聚合、资源库、工厂来管理模型对象的生命周期。代码就是领域模型的直接映射,减少中间翻译。


前几年,业务中台的概念被人们提及,表明比特世界的触角伸向业务的纵深,业务复杂度进一步提升。在可预见的未来工业互联网、物联网、ToB 业务的需求会猛增,软件的长期趋势是软件会被应用于解决越来越复杂的问题,越来越深入这些业务的核心。面对越来越复杂的业务问题,开发人员应该以登高望远的姿态,“不畏浮云遮望眼”,坚持不懈的进行领域驱动设计的实践,掌握领域驱动设计的方法,它就是我们应对软件核心复杂性的法宝。


在开篇我们先给大家提供一张思维导图,让大家对领域驱动设计有一个总体印象:


发布于: 刚刚阅读数: 2
用户头像

worry

关注

心若有翼,我自飞翔 2018.01.25 加入

一个戴着眼睛的肥胖的扑腾蛾子

评论

发布
暂无评论
实战领域驱动设计开篇