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