专栏首页软件开发-青出于蓝读张逸的领域驱动设计之应对软件复杂度笔记 原

读张逸的领域驱动设计之应对软件复杂度笔记 原

    Eric Evans认为"很多应用程序最主要的复杂度并不是技术上,而是来自域本身、用户的活动或业务"。最终决定的因素还是因为需求。

需求引起的软件复杂度

    需求分为业务需求和质量需求,因而需求引起的复杂度可以为俩个方面:技术复杂度与业务复杂度。

  1.     技术复杂度来自于需求的质量属性:诸如安全、高并发、高可用,为软件设计带来了极大的挑战。
  2.     业务复杂度对应了客户的业务需求:这种复杂度往往回随着需求规模的增大而增加。

技术复杂度与业务复杂度并非完全独立,二者混合在一起产生的化合作用更让系统的复杂度变得不可预测,难以掌控。

当我们面的一个相对复杂的软件系统时,通常面临的问题在于:

  • 问题域过于庞大而复杂,使得从问题域中寻求解决方案的挑战增加,该问题域软件系统的规模有关。
  • 开发人员将业务逻辑的复杂度与技术实现的复杂度混淆在一起,该问题域软件系统的结构有段。
  • 随着需求的增长和变化,无法控制业务复杂度和技术复杂度,该问题与软件系统的变化有关。

领域驱动设计的应对措施

    隔离业务复杂度与技术复杂度,要避免业务逻辑的复杂度与技术实现的复杂度混淆在一起,首要任务就是确定业务逻辑与技术实现的边界,从而隔离各自的复杂度。领域驱动设计通过分层架构与六边形架构来确保业务逻辑与技术实现的隔离。

分层架构的关注点分离:分层架构遵循了"关注点分离"原则,具体表现在,将属于业务逻辑的关注点放在领域层(Domain Layer)中,而将支撑业务逻辑的技术实现放到基础设施层。

六边形架构的内外分离:目前还不是很理解,待深入。

限界上下文的分而治之

更新中......

(adsbygoogle = window.adsbygoogle || []).push({});

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 架构之技术复杂度与业务复杂度 原

        今天给自己提出一个问题,如何在项目代码中,如何将技术复杂度与业务复杂度分开,我以前从未想过这个问题,直到看到张逸的领域驱动设计。

    克虏伯
  • Linux之shell记录 原

        vim分为普通模式和插入模式,在普通模式下按下i就进入插入模式,在插入模式下按下ESC就回到普通模式。

    克虏伯
  • J2EE中搭建hibernate 原

    注意:如果只是搭建hibernate的话不需要再Web.xml中配置hibernate信息

    克虏伯
  • 数据结构和算法

    10个算法:递归、排序、二分查找、搜索、哈希算法、贪心算法、分治算法、回溯算法、动态规划、字符串匹配算法。

    分母为零
  • 数据结构与算法 1-4 常见时间复杂度与大小关系

    本系列是我在学习《基于Python的数据结构》时候的笔记。本小节主要介绍一些常见的时间复杂度以及它们之间的大小关系。

    触摸壹缕阳光
  • 昨天的文章,有朋友给出"更好的"解法,其实并不是...

    昨天推送一道题目分析,一方面学习一个颇具特色的数组,它的取值不大于数组长度;另一方面通过这道题充分体会算法分析、逻辑推理的重要性。只有做好充分的分析,才可能写出...

    double
  • 02 复杂度分析_pythoner学习数据结构与算法系列

    设计算法时,时间复杂度要比空间复杂度更容易出问题,所以一般情况一下我们只对时间复杂度进行研究。一般面试或者工作的时候没有特别说明的话,复杂度就是指时间复杂度...

    诡途
  • 常用算法解析

    算法基础:概念,时间复杂度,空间复杂度,常见算法以及复杂度计算 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?...

    wangxl
  • 笔试常考题型之时间复杂度

    Zoctopus
  • 笔试常考题型之时间复杂度

    Zoctopus

扫码关注云+社区

领取腾讯云代金券