前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >领域驱动设计门槛很高,没有深厚的面向对象编码能力很难实践成功

领域驱动设计门槛很高,没有深厚的面向对象编码能力很难实践成功

作者头像
春哥大魔王
发布2020-11-09 11:26:13
9410
发布2020-11-09 11:26:13
举报

时间是人类最宝贵的资源。时间是有限的、不可再生的,你可以用钱买任何东西,却买不了时间。技术,就像时尚,在以光速在变化着。为了赶上它,我们需要跑的非常快。但是这个跑道上没有终点,所以没有赢家。

将你的黄金时间用于学习通用技能,那些不会过时的技能。

  • 不要学习微服务框架,学习演进式架构(Evolutionary Architecture)。
  • 不要学习新的编程语言,学习代码整洁之道、设计模式、领域驱动设计(DDD)。
  • 不要学习 Less 和规模化敏捷框架(SAFe),学习精益生产原则。
  • 不要学习 Hystrix,学习容错模式。
  • 不要学习 Docker,学成持续交付。
  • 不要学习 Angular、React 和 Vue,学习 Web、HTTP 和 REST。

领域驱动是解决软件复杂度的利器,也就是说软件业务越来越复杂了,领域驱动设计可以让事情变得简单。

领域驱动设计是一套方法论,指导我们将复杂问题进行拆分、拆分出各个子系统间的关联以及是如何运转的,帮助我们解决大型的复杂系统在落地中遇到的问题。

领域驱动之外的架构方式都可以归纳为以数据为中心的架构方式:

  • 当软件在开发初期,以数据驱动的架构方式非常容易上手,但是随着业务的增长和项目的推进,软件开发和维护难度急剧升高。
  • 领域驱动设计则在项目初期就处在一个比较难以上手的位置,但是随着业务的增长和项目的推进,软件开发和维护难度平滑上升。

但是很多人把领域驱动设计“神话了”,很多时候为了“领域”而领域,结果反而造成了“复杂度”的出现。什么意思呢?

其实领域驱动的出现逻辑在于,我们以前的设计太围绕于“数据模型了”,造成了后续基于业务发展导致的系统僵化的问题,于是提出来了“领域驱动”这个概念,就是说我们需要考虑到业务系统的各种演进的可能,而不要尝试将业务直接翻译成数据,再去做架构。而是让业务和架构直接相连,那么“领域”就很重要了。

那么领域驱动设计的核心是什么呢?

战略设计+战术设计。

战略设计部分指导我们如何拆分一个复杂的系统,战术部分指导我们对于拆分出来的单个子系统如何进行落地,在落地过程中应该遵循哪些原则。

在战略设计层面提出了域、子域、限界上下文等重要概念;

在战术设计层面提出了实体、值对象、领域服务、领域事件、聚合、工厂、资源库等重要概念。

域对应一个问题空间,子域是把域这个大的问题空间拆分成若干个小的更容易解决的问题空间,也就是单体应用向微服务演进过程中划分出来的各个子系统;

限界上下文是解决方案空间,每个子域对应一个或多个解决方案空间。微服务的划分是也是将一个大的问题拆分成若干个小的问题,每一个小的问题用一个或多个微服务来解决。

说到战略设计,我们要站在一个比较高的视角来看待这个问题,战略设计要解决的就是某个领域的问题,所以战略设计时,我们要构建好领域模型,保证我们的大方向是不会错的

战略设计主要从业务视角出发,建立业务领域模型,划分领域边界,建立通用语言的限界上下文,限界上下文可以作为微服务设计的参考边界。

比如同样做一个供给相关的toB系统,你是处于新零售业务场景,还是O2O业务场景,亦或是线上电商场景,这些往往决定了你最后的架构的方向和实现的不同。

所以我们在做一个大型、复杂的业务系统设计之前,需要画出一个全局的能力地图,也就是在所处的业务方向上,部门级别的业务能力地图,之后分析哪些是属于你这个团队所持有的,哪些是需要配合的,哪些是基础能力,哪些是通用能力,哪些是商业能力,哪些是开放能力,哪些画到业务中台,哪些是技术中台的事情。

这些如果不设计好的话,就会进入一种为了“领域”而“领域”的情况,就是一堆人开始跑去画流程图、画交互图、画架构图了,这样的设计思路我相信是会出返工的问题的。

领域驱动设计中的战术设计部分就是指导我们如何落地一个系统才可以使系统具备高可扩展性、高可读性。

所有的系统最终都要以代码的形式落地,而落地的工作都是由普通的开发同学来做的,系统是否具备高可扩展性、高可读性直接影响了整个团队的效率。

战术设计则是要求我们从业务模型转向微服务落地 我们会将领域模型中的领域对象与代码模型中的代码对象建立映射关系,将业务架构和系统架构进行绑定。当我们去响应业务变化调整业务架构和领域模型时,系统架构也会同时发生调整,并同步建立新的映射关系。也有演进式架构的含义在里面。

说到这里,大家可能对DDD有了一个粗略的,大体的认识,我们可以理解到,DDD能够帮助我们更好的在微服务的架构中进行合理的拆分,由于DDD要求我们建立标准的业务领域模型,所以DDD也能够很好地帮助我们设计企业的中台,DDD是一把利器,帮助我们解决架构中遇到的问题和挑战。

为了不过分神话领域驱动,我们需要降低一下对于DDD的期望,DDD是一套完整而系统的设计方法,并非一种架构。它能带给你从战略设计到战术设计的标准设计过程,使得你的设计思路能够更加清晰,设计过程更加规范,有助于提高技术人的架构设计能力。软件系统的核心只有两个:领域和算法。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2020-11-02,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 春哥talk 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档