群里经常看到类似于“看了DDD之后就不会写代码了”的情况，趁最近学车的间隙，写写我的看法。
关于这个事儿，我是觉得：当没有DDD的时候，如果你知道怎么做，那就那么做好了，不要考虑DDD。
当然不是说学了不用，而是在无法直接与实际做对应的情况下，先不要对应，慢慢来。这是一套方法论，而不是具体的方法，它更多的是给一个对当前系统复杂性手足无措的人一个思路。其中聚合那一部分只是个前提，并不是DDD的重要部分。
初做设计，学习DDD的时候，边看书可以边将内容与面向对象的各种设计原则、基本准则做对比，储备相关知识，领会面向对象的精神。学习设计的时候，完全没必要去考虑DDD该如何落实到代码这种程度。在我看来，DDD就是一种面向对象的最佳实践，就像设计模式是面向对象基本原则的最佳实践一样，当一个新手不知道如何写代码，可以选择性的模仿。
虽说不是系统简单就用不了DDD，“每行代码都是一个设计”，但是初学者应该是在手中的系统变得越来越复杂，涉及的业务对象越来越多而感到困扰的时候，才是能真正利用上DDD。一个新进的设计者这时借助DDD的思路去规划业务、去与其他团队协作，或许才能体会出其中的好处。
当年初出茅庐，遇到了些业务庞大、逻辑复杂的系统。在思考如何解决复杂性的时候，其实已经将业务对象封装成类似“聚合、聚合根”的形式了。只是项目推进的过程遇到了很多问题，也没有根据变化情况区分层次。然后顺着这些问题找到了DDD，它系统地解决了我的问题，并指出了一个方向。
虽说理想情况下是系统逐渐变得复杂，通过敏捷的方式按部就班的演进系统。但是也会有半路接手的问题，这些都是要在方法论思路的指导下灵活掌握的。至于一开始就很复杂的系统，完全可以在T型集成之类的方法下，持续敏捷的去做，就当作是系统再逐渐复杂也无不可。
虽说学习都是从模仿开始的，但DDD应该是模仿其解决复杂性的思路，而不是实现的代码，开发技巧这种层面的事儿。这方面，公众号里只发过两篇(以前博客园博客还写过一些，不过没整理过来)，大概谈过这类内容，大家可以参考：《DDD概述》、《观画有感之软件开发》。虽然现在看来也有些可以商榷的地方，但是对初学者应该还是不错的。
最后，我想顺便说一下和微服务的事儿。我认为DDD和微服务是完全不同的两个东西，虽然在一些条件下，它们比较契合。微服务更多的是从技术和团队组织结构上划分的，DDD的子域更多的是从业务逻辑、业务稳定程度方面划分，很多时候确实会有重叠。但学习DDD的时候还是忽略这些重叠比较好，混淆了就出不来了。如果有特别情况，比如中台的业务逻辑按各自领域提供服务，而某一个特别功能的访问量奇大，那它的部署，服务间引用与业务的紧密程度可能并不对应，会需要取舍。
转 https://www.cnblogs.com/saaav/p/16623462.html
标签：建议,代码,系统,业务,面向对象,使用,时候,DDD 来源： https://www.cnblogs.com/wl-blog/p/16634880.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。