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

    张逸的《领域驱动战略设计实战》地址，付费的，价格￥59，还能接受。

    Eric Evans认为"不少应用程序最主要的复杂度并非技术上，而是来自域自己、用户的活动或业务"。最终决定的因素仍是由于需求。

需求引发的软件复杂度

    需求分为业务需求和质量需求，于是需求引发的复杂度能够为俩个方面：技术复杂度与业务复杂度。

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

技术复杂度与业务复杂度并不是彻底独立，两者混合在一块儿产生的化合做用更让系统的复杂度变得不可预测，难以掌控。

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

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

领域驱动设计的应对措施

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

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

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

限界上下文的分而治之

        

更新中......