群里经常看到类似于“看了DDD之后就不会写代码了”的情况，趁最近学车的间隙，写写我的看法。
关于这个事儿，我是觉得：当没有DDD的时候，如果你知道怎么做，那就那么做好了，不要考虑DDD。
当然不是说学了不用，而是在无法直接与实际做对应的情况下，先不要对应，慢慢来。这是一套方法论，而不是具体的方法，它更多的是给一个对当前系统复杂性手足无措的人一个思路。其中聚合那一部分只是个前提，并不是DDD的重要部分。
初做设计，学习DDD的时候，边看书可以边将内容与面向对象的各种设计原则、基本准则做对比，储备相关知识，领会面向对象的精神。学习设计的时候，完全没必要去考虑DDD该如何落实到代码这种程度。在我看来，DDD就是一种面向对象的最佳实践，就像设计模式是面向对象基本原则的最佳实践一样，当一个新手不知道如何写代码，可以选择性的模仿。
虽说不是系统简单就用不了DDD，“每行代码都是一个设计”，但是初学者应该是在手中的系统变得越来越复杂，涉及的业务对象越来越多而感到困扰的时候，才是能真正利用上DDD。一个新进的设计者这时借助DDD的思路去规划业务、去与其他团队协作，或许才能体会出其中的好处。
当年初出茅庐，遇到了些业务庞大、逻辑复杂的系统。在思考如何解决复杂性的时候，其实已经将业务对象封装成类似“聚合、聚合根”的形式了。只是项目推进的过程遇到了很多问题，也没有根据变化情况区分层次。然后顺着这些问题找到了DDD，它系统地解决了我的问题，并指出了一个方向。
虽说理想情况下是系统逐渐变得复杂，通过敏捷的方式按部就班的演进系统。但是也会有半路接手的问题，这些都是要在方法论思路的指导下灵活掌握的。至于一开始就很复杂的系统，完全可以在T型集成之类的方法下，持续敏捷的去做，就当作是系统再逐渐复杂也无不可。
虽说学习都是从模仿开始的，但DDD应该是模仿其解决复杂性的思路，而不是实现的代码，开发技巧这种层面的事儿。这方面，公众号里只发过两篇(以前博客园博客还写过一些，不过没整理过来)，大概谈过这类内容，大家可以参考：《DDD概述》、《观画有感之软件开发》。虽然现在看来也有些可以商榷的地方，但是对初学者应该还是不错的。
最后，我想顺便说一下和微服务的事儿。我认为DDD和微服务是完全不同的两个东西，虽然在一些条件下，它们比较契合。微服务更多的是从技术和团队组织结构上划分的，DDD的子域更多的是从业务逻辑、业务稳定程度方面划分，很多时候确实会有重叠。但学习DDD的时候还是忽略这些重叠比较好，混淆了就出不来了。如果有特别情况，比如中台的业务逻辑按各自领域提供服务，而某一个特别功能的访问量奇大，那它的部署，服务间引用与业务的紧密程度可能并不对应，会需要取舍。
