咱们先不热议DDD的界定，先整理某些DDD火下去的情况，依据我学习的技巧，始终是为什么为首，再是处理什么问题，是什么东西，最后怎么使用。大家都了解这么多年伴随着设备及其技术的发展趋势，软件体系结构发生了许多改变，从最开始的单机（BS/CS）构架到后来的集中型构架，再到目前的分布式架构，目前基本上能够 说成分布式架构流行的时期，DDD早在04年就由阿德里安·布拉德利明确提出，但始终处在1个不咸不淡的情况，直至MartInFowler5的《Microsservices》引发大伙儿留意，也就是微服务架构流行以后（这里须要表明的是，微服务架构最开始的明确提出者不是MartInFowler5，反而是FredGeorge），DDD再次回到大家视野中间，为什么呢？
咱们先了解一下3种技术架构的演变及其关键差别：
第一个环节是单机构架，特点是所有设计开发紧紧围绕着网站数据库开展设计方案和设计开发。
第2个环节是3层式的集中型构架，选用面向对象编程的设计方法，领域模型分业务流程层、逻辑层、信息浏览层，这类构架非常容易某一层层或是多层越来越松垮，扩展性较弱，此外颠覆性创新无效，一台机器能力比较有限。
第三层环节是分布式架构，在集中型构架中，结构化分析、设计方案和设计开发通常是单独开展的，并且每个环节责任人将会不同，那样就牵涉到信息交流丢失的难题，此外项目从深入分析到设计开发历经的过程较长，非常容易最后设计开发与需求完成的不同，微服务架构关键便是处理第二个环节的这种痛点，完成APP两者之间的解耦，处理单个APP扩展性的难题。
微服务架构存在的不足
进到微服务架构以后，解决了集中型构架的单个APP许多难题，可是新的难题应时而生，微服务架构的粒度分布需要多少？微服务架构怎样设计方案呢？微服务架构怎样分拆？微服务架构界限在哪儿？
很长一段时间大家也并没有处理这一难题，就连MartInFowler5在明确提出分布式架构的情况下也并没有告知我们这该怎样分拆微服务架构。
乃至在较长的日子里大家对微服务架构分拆形成了某些误会，有些人觉得：“微服务架构非常简单，便是将以前的单个APP拆分为好几个布署包，或是将原先的单个应用架构更换为一整套支持微服务架构的技术架构，就算是微服务架构了。”也有人觉得微服务架构需要分拆得越低越好。
因为以上情况，许多项目因为早期分拆过多，造成复杂度过高，造成末期无法运维管理乃至无法上线。
能够 得出1个结果：微服务架构分拆困局形成的直接原因便是不清楚业务流程或是微服务架构的界限究竟在哪儿。也就是说，明确了业务流程界限和APP界限，这一困局也就得到解决了。
而DDD便是解决了这一明确业务流程界限的难题，由此可见DDD并不是1种技术架构，反而是1种区划业务流程行业区域的系统论。DDD的盛行是因为许多了解领域驱动模型(DDD)的技术工程师在开展微服务架构设计方案时，发觉用DDD的思路开展业务流程整理能够 非常好整体规划服务界限，能够 非常好完成微服务架构内部和外部的“高耦合性、低耦合”。因此愈来愈多的人将DDD做为业务流程区划的指导方针。
还没有评论，来说两句吧...