我对DDD的粗浅理解
- 网上关于DDD的基础和实践已经很多了，这里就赘述了，主要是本人也不专业，在实际工作的项目中，还没实践过。
- 在这里仅记录目前个人对DDD的实际使用场景的粗浅理解，很可能是错误的认识。不讲细节，仅做记录。
- DDD对开发人员的要求更高，对DDD的理解不够透彻，或者单兵作战的情况下，可能使本来逻辑简单的代码写得更加复杂了，别人接手很难看懂，浪费大家的时间，反而没提升开发效率。
- 是否使用DDD，需要看具体项目而定，业务变更多，创新类项目，其实是不适合用DDD的。因为这类项目产品变更多，特别是互联网中面向用户的业务系统，更是变化莫测，你永远想不出产品下一步想出什么。总结来说，这类项目有以下特点：
- 新业务，新需求，各种不确定
- 可能随时就放弃的业务，没必要花太多精力
- 需要快速上线，DDD需要前期花很多时间抽象概念，以便后续通用复用，实际这类项目产品也没想清楚具体怎么分类，也无法确定，花费这个时间不值得。
- 什么项目合适用DDD呢？个人认为有
- 概念和需求变更较少的项目，很多公司都基本都有的项目（非特有的），比如财务系统，订单系统等，业界都有一系列共识的业务基本概念和定义。
- 基础系统，业务中台系统，这类项目基本可以基于现有的业务情况，通过抽象和重构的方式，重新定义DDD的域和限界上下文(Bounded Context,BC)的划分，以及各个限界上下文之间的上下游关系。这种长期有收益的项目值得投入精力，以便后续快速复用和扩展。
- 是否使用DDD还跟公司的组织和氛围有关系
- 组织经常变更，项目谁都可以维护，使用DDD只会增加后续其他人的维护负担。我认为只有对一个项目有一定的熟练度，才能更好的使用DDD，否则到处理解每个项目的DDD，粗浅的用DDD，不方便刚开始的理解，也因为不熟悉把代码写复杂了。
- 对于想快速上线，不尊重软件工程重要性，代码维护重要性，只追求直接受益的公司，也不合适用DDD。
