
课程咨询: 400-996-5531 / 投诉建议: 400-111-8989
认真做教育 专心促就业
领域驱动设计是目前大多数软件开发程序员都在学习和使用的一种软件架构方式之一,下面我们就通过案例分析来了解一下,领域驱动设计常见问题分析。
1、DDD和微服务架构什么关系?
我觉得微服务架构是DDD的佳实践,尤其是在战略上面:微服务架构中的每一个服务都对应了一个DDD中的BC;BC的设计可以指导微服务架构中服务的划分。在我初学DDD的三四年里,当时理解度很不够,但仍能觉得分出这么多BC后,服务的运维、部署、研发的难度一定会巨大。有的时候一个业务跨多个BC,仅就部署的工作就是个大的难题。可以这么说,DDD出来之时就是一种跨时代的产物,您所能实践的并不多。而随着容器、微服务框架等技术的发展,DDD才有了发挥的空间。
2、单体架构是不是违反了DDD思想?
不存在这个概念。单体与微服务架构是两种不同的架构风格,具体您使用什么系统与系统的需求、公司的组织结构、资源配给、技术积累等有着巨大的关系。虽然DDD推崇使用微服务架构,但当条件达不到时不要勉强。还是那句话,DDD思想的重要性要大于某一个具体的战术模式。我见过一些写微服务架构技术的文章,极力反对单体甚至将其鄙视的猪狗不如,这种态度就太扯犊子了。微服务架构的确先进,那东西也有它的局限性的。有一次面试,面试官大力的炫耀:我们这儿,每个接口都是一个服务。说这种话的人一般也是近亲结婚的产物,一笑置之即可。有这样一种理论我觉得有点意思:微服务架构能实现服务间的解耦,对应的组织结构也需要进行调整以实现微服务研发团队间的解耦,只有两者匹配时才能实现生产力的大化。我觉得这话老有道理了,这几年被部门墙和团队墙折磨的着实够劲儿。
3、BC的作用到底有哪些?
三个作用。1,系统部署的基本单位,BC对一个大系统在物理结构上进行了划分尤其在使用微服务架构落地时效果更为明显。以BC为单位,大的系统被分割成物理上独立的、可单独部署的小服务,仅就其隔离作用所带来的优势也是单体不具备的;2,确认了领域术语,让每个业务概念在BC中的含义是明确的、精准的;3、为领域模型划分了作用边界,避免出现超级类。比如电商中的“用户”概念,在“订购”BC中主要关注会员、优惠等级等与订购活动相关的属性;在“物流”BC中主要关注地址、联系方式等与收货、物流相关的属性;在“营销分析”BC中会关心其购买记录等信息;在“账户管理”BC中主要关心其基本属性的录入、管理等;在“支付”BC中则需要关注其账户余额、交易流水等。如果没有BC的隔离,您可能就需要建立一个巨大的类包含:地址、优惠等级、联系方式、购买记录、商品评价、账户金额等全量的信息。存储一个客户信息搞不好需要建立一个包含100+字段的表,现实中我遇到过这种情况,没人敢接手代码维护。
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销,赚更多好礼。