DDD的初步理解

        DDD全程是Domain Driven Design，领域驱动设计(软件核心复杂度应对之道)。是一种软件设计理念，目的是在业务规则即使变的越来越复杂的情况下，也能保持软件的可扩展性、可维护性以及可测试性。

        软件核心复杂度是什么？我觉得从变化的角度才能彻底理解。首先是业务规则，没有哪一个软件能从一开始就预测所有的应用场景，业务规则的变化也就是自然而然的事情了。其次是数据存储的变化。一般数据的存储采用某种数据库，这种数据库在业务刚开始的时候是合适的。然而业务的增长，数据量的增加，可能这个数据库就不那么合适了，需要重新选型，之后还要将数据从旧的数据库迁移到新的数据库--这个迁移异常耗时耗力。第三是与外部的交互。外部交互中容易引起业务发生变化的一种是UI的展示，一种是外部系统的的变化。UI根据角色的不同展示不同的数据，一般的解决方式是给出权限最大的角色需要的数据，其他角色不需要展示的数据就把对应的字段值设置为空再返回；虽然字段出现了冗余，但确实最容易的实现方式。外部系统的变化在控制之外，会发生什么变化，如何变化都可能会影响到自身，没人愿意因为一个外部依赖的变化在整个代码仓中寻找引用点然后一个一个去改动。DDD为解决这些问题提供了一种思路。

        DDD的一个重要理念是核心业务逻辑的代码部分与周边可能变化的支撑相互隔离，并且使用的是业务语言，按照业务模型去组织代码，使开发人员和业务人员能更好的协作。DDD如何做到与变化的部分相隔离？首先是采用分层结构，每层各司其职，层级之间的依赖关系有严格的要求。其次是采用防腐层。所有为的防腐层就是面向接口编程，接口的入参和出参都是本领域中定义的对象，外围使用的数据则根据需要做转换，即核心逻辑只关心做什么，怎么做是具体实现的问题。

        DDD提供很多的概念来辅助解决软件的复杂性，如实体、值对象、聚合、聚合根等。随着对这些概念的理解，DDD更像是为了这个设计理念提供了一种编码规则，按照这套规则能更容易代码落地。但是随着业务复杂度的增加，实体、值对象、聚合、聚合根以及各概念之间的关联等的划分变的不那么清晰，一旦划分错误，后期修正的成本将变的巨大。我觉得这是DDD难于落地的根本原因。