1.架构概述
引语:在我多年的职业生涯中,我发现就算是互联网公司,大部分部门也是由业务驱动,业务决定了我 们的技术选型以及代码边界。也就是说我们并不是一定需要对于所谓的架构标准进行墨守成规。并且市 面上大多数项目并不能直接体现出架构专业度以及架构特性。不过领域驱动设计又是我们互联网大厂必 问的这样一个问题。所以我希望能够将领域驱动设计结合业务场景进行解析。这里补充说明一句, DDD(领域驱动设计)实际上是一套软件架构设计的方法论,我们可以在此之上更好的理解业务。并且 我们可以根据这套方法论进行架构风格填充,包括微服务架构,面向服务架构,REST
风格架构以及六边形架构等等。并且我们还能够将上述的架构风格进行结合使用。架构风格本质上就是一组架构约束。也 就是说他其实就是规则。
领域驱动本身不涉及任何的技术栈,很多同学很喜欢聊微服务,那是因为微服务本身就有实现以及 落地,但是领域驱动这么多年以来,其实并没有一个实现以及落地。
其实来领域驱动设计
DDD
的各位同学,其实你们也应该发现了,当你们浅浅的去看领域驱动设计的 时候,你会感觉领域驱动设计好像非常契合我们的业务场景,并且感觉非常的规范,但是我不得不 说这是你们的错觉。每一个程序员刚接触到DDD
的时候都是这个感觉。
你的业务经验越丰 富,实际上你的理解越深入 领域驱动设计并没有一个完整的规范或者说约束,现今市面上你所看到的所有资料都是基于(Eric Evans)埃里克
·
埃文斯的《领域驱动设计
-
软件核心复杂性应对之道》这本书进行衍生,本课程是我
对于领域驱动设计的理解。所以不要拿这里的概念与市面上一些概念进行对比。
2.领域驱动模型不得不说的秘密
2.1 业务决定技术边界,业务边界定义领域模型
2.1.1 什么是领域驱动设计
什么是领域驱动设计
实际上领域驱动设计的英文是
Domain-Driven Design[d
ɪˈ
za
ɪ
n].
为什么会出现一个这样的概念呢?这是由于软件其实对于行业并没有什么非常高的要求,因为软件本身 就是为了能够帮助某一些业务进行更好的发展。软件本身其实是赋能以及变革。软件具有行业兼容性, 同时又带来固有的复杂性。
比如医疗行业跟金融行业,都能够去使用软件进行业务开发,但是他们的业务完全不一样,这个时
候我们就需要进行大量的业务梳理,甚至需要专门的岗位(产品经理)去完成这个工作。而完成这
项工作之后,我们才会进行软件的设计层面,在软件设计的时候,由于信息层层传递,就有可能会
导致信息的失真以及遗失,从而导致产品预期以及产品落地会产生较大的差异性。