随着互联网的不断发展,越来越多的程序员都在学习领域驱动设计的开发方式,而今天我们就通过案例分析来了解一下,领域驱动设计开发发展趋势。
确切地讲,DDD这种模式语言为许多知道如何做但不知道如何有效沟通协调的开发人员和设计人员提供了明确的语言。
但我生气的是,近,似乎任何时候,当有人谈论如何设计系统或服务边界,或者只是提到非技术设计时,每个人都感觉不得不引进DDD专家——好像他们是可以设计这些东西的超级英雄。这和其他类似的情况一样糟糕,你盲目地应用当前流行的解决方案,仅仅因为它是每个人都在谈论的事情,而不是因为它是这项工作的正确解决方案。
DDD很棒,但它只是你应该注意的众多工具和技术之一。
在DDD的战略维度中,常用的工具是“有界上下文”的概念——一个给定的模型通常可以,而且应该被细分为更小的单元,每个单元为特定的概念赋予符合它们自己上下文的特定含义。好主意!这(当然)也不是DDD的发明:它只是简单的模块化设计,已经被设计大型系统的人们应用了几十年。
这是否意味着有界上下文的概念有问题呢不,事实上,该模式的目的是为已经存在并证明了其价值的东西命名。我并不是说有界上下文有什么问题,我只是想指出,有些人可能在没有使用或甚至不知道这个特定称谓的情况下做了出色的系统设计。
在战术层面,人们忽略了一个更重要的方面,特别是当他们将DDD作为设计入门时。DDD强调命名的重要性,并建议你在设计中尽量使用一种通用的、普遍存在的语言。但对于系统设计领域,它也使用自己的语言——诸如有界上下文、聚合、实体、值对象等概念。虽然这些都很好,但它们只是一种可行的语言。将一个值对象称为值对象是有价值的,如果这是一个很多人都理解的术语,就会有助于交流。
但是,现有的、常见的DDD概念并不是你应该考虑的概念——它们只是设计和架构系统时一些非常常见的特征的范例:提出并识别模式,给它们起个名字,并使用它们来给出系统结构,保证系统统一性。如果在你的架构中,有一种常见的模式,你使用一个Filter将请求路由到一个Handler,或是使用一个由Agent处理的概念Document,那么这类事情可能会多次发生,和服务或存储库在同一层次上,终变成对你而言更重要的东西。这很好!
我们可以并且应该发明自己的语言,这种思想比许多天真的DDD从业者所认为的要重要得多。我相信DDD专家对此非常了解,并将任何DDD材料视为起点,而不是终结果。但是,如果你所做的一切都是按照现有的DDD标准术语定义,并试图将任何问题都硬塞到现有的结构中,那么你的生活将非常悲惨。
希望这辈子,最让你无悔的事情就是来达内学习!学习向来不是件易事,但无论过程多么艰难,希望你依然热爱生活,热爱学习!永远记得,达内将与你一同前行!现在扫码,立即领取万元课程礼包,助力0基础快速入行,为你梳理行业必备技能,全方位了解岗位发展前景!
【免责声明】:本内容转载于网络,转载目的在于传递信息。文章内容为作者个人意见,本平台对文中陈述、观点保持中立,不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。