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

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

需求引起的软件复杂度

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

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

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

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

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

领域驱动设计的应对措施

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

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

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

限界上下文的分而治之

更新中......

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