对领域驱动设计的初步认识的一些看法

13-01-09 wldst

看了flyzb 的对领域驱动设计的初步认识博客及其相关讨论。
上面很多关于DDD的领域、业务、模型等相应的讨论，先不说谁对谁错，反正大家都是争论不休，同时也是概念不清晰。下面说说我对DDD的一些看法和想法以及理解。
领域：具有排他性，领域可大可小，领域就是个圈子。在我的领域我做主，领域外的东西是不是最能够描述领域里的东西的。
既然说到DDD就要说到模型。

模型：如同加法：加数，与被加数。加法这个算法可以适合多种领域，多种业务，多种算法。
其实模型有的时候给我的感觉就是数据结构。
模型能够解决的问题就如同数据结构与算法能够解决的问题。

说到这里，其实模型就是构成现实世界的内在或大或小的组成部分，
在物理领域里面是同电子，质子，原子，分子。
在计算机里面是0和1，是数据结构，是算法。
在化学里面是共价键，（正负）离子。氢氧基。
在生物里面就是基因、染色体、线粒体、细胞、组织、器官、生命体、物种、种群、部落、社会，国家（一国两制就包含两中社会，还有白社会和黑社会之分，甚至是江湖之分）。
这里的这些都是领域模型中的领域语言的语法单元，如同化学语言，物理语言，生物语言的基本语法单位。
领域：一般都有领域语言，是领域里面的最特有的，是领域专家对领域的描述。
是有上下文，有专业知识的，不需要领域以外的人看懂的（具有领域知识的人除外）。某个领域就是解决某个或者某类问题的。领域语义都是在领域里面有效的。化学语言到了物理里面，基本上可以说是不好沟通。因为他们不需要沟通。它们是特定领域的专业知识。
在比如数学吧，数学却是所有领域里面的基础。数学模型，可以适用很多领域。
当然数学的很多语言在其他仅仅是部分适用。数学其实是一个通用语言。通用模型。但是数学是不表达意义的。只是数值的效果。
只有结合具体的场景和上下文。才能够产生真实的意义。看得见摸得着的意义。
就如同原子弹，氢弹的模拟爆炸数值。在数学上就仅仅是一个数字，但是当数学结合特定的领域。他的意义就表达出来。

数学应该来说是只一种公用的领域。它是通用的元语言。
其他的通用元语言还包括，字母表，乘法表，阿拉伯数字，符号体系。还有就是我们生活的中的各种人类语言。如汉语，英语。
我们思维最终都是要经过人类语言的表达才能够真正理解这些语言要表达的意义。所有的语言都要通过人类语言表达。才能够被人类所理解。
这里总结一下：
人类思维--》人类语言--》领域语言--》通用领域语言（元语言）--》领域特定语言（DSL：具有唯一性和统一性）。
人类语言：各个地区的语言，方言。通用语言。英语：法语、俄语、日语、汉语、阿拉伯语。
人类是不是本身就有个操作系统：而人类的语言就如同汇编语言。不同地域的语言-方言。民族语言，国家语言。使用的语言不一样，
操作系统的执行效率就不一样。那么人类跨平台的语言又是什么？在计算机的世界里是java。
人类或许能够在计算机世界里实现跨平台--这个由不同人类语言思维的构成的人类操作系统。

计算机语言：不同级别的语言。
汇编--》C语言--》C++语言--》java语言
其中SQL是个怪异的语言。SQL语言中还是因平台差异化。感觉和底层又很靠近。

人类的通用语言是什么？或许就是计算机语言。对于程序员来说，程序语言是跨国界的。是通用语言。同时也说明了一个道理。
某个领域里面的成员都能够听懂的话就是领域语言。不管领域里的成员来自何方，来自哪个语言区。
领域语言是能够表达本领域的东西，同时也只在本领域里通用。就如同化学，数学，物理等等。
领域语言具有通用性。只要领域语言被正确使用在其领域里，就可以是跨国界，跨种族。跨时区，跨空间的被使用，被运用。
所以做任何事情前，如果把该事情给描述清楚出了。表达清楚了。就会在一个领域里面被无歧义的被执行。
这里所说的领域可以是团队，项目，部门，公司，集团，行业甚至是国家。从领域的角度来看，其实国家是属于少数人的，
大多数的人是属于国家的。高层领域下发的各种独特指令，精神，被逐层给翻译执行。最终影响到国家的相应部分，
就如同应用程序：下发的各种指令被各种层次的协议，语言，最终完成应用程序的功能。

为什么人类会存在如此多的语言？是领域所决定的。因为领域太多了。这里也说明了，有多少领域就应该有多少领域语言，亦或是领域就是以语言进行区分的，领域的边界就是语言的边界，但是有多少领域语言不等于是有多少领域，因为有很多领域语言可能是同一层次等效的就如同英语，汉语是可一个翻译的。当然领域也有。所以领域不等于业务，业务其实是在各种组织中一个通用的说法。业务大体是说了干什么用的。做什么的。解决什么问题的。但领域却不是为了描述某一件或者摸一个目的的。
业务其实是和场景相关的。相互交错，场景中包含业务，业务中包含场景。比如：在什么场景下才有了业务，业务存在于某某场景下。
业务又包含了某某场景。

场景就是对某个时刻，某个特定的时空的定义。

最经典的就是舞台场景，一个故事有多个场景构成。一个场景包含多个故事。故事算不算是业务呢？特别是在工作上，计算机环境里，公司，部门，组织。业务就是各个部门的日常活动。其实这里的部门只是一个代指。它可以是单位，部门，岗位，员工。

业务就是为了达到某种目的，而需要去做的哪些事情，参与的哪些活动等。我们做需求的时候需要了解用户故事。通过故事来分析业务。
在故事和业务的共同驱动下了解业务的逻辑，分析出业务由哪些事情构成。

真正的业务就是要做的那些事情和活动。现实世界是个动态的世界。然而这些事情和活动就可能涉及到其他不同的业务，
其他不同的领域。进而产生其他的业务。然而业务又出发某个时间，产生某个场景。就如回家事件，上车事件，上学事件，乘飞机事件的发生。
我们相应的进入到某些场景中去。就比如过马路事件很可能有危险，引发其他事件，引发其他业务，引发其他场景。从这里来说的话，
其实事件就是各个场景的联系和消息传递。比如过马路事件正在发生时，发生了交通事件。该交通事件被交警检查到（监听到）或者被行人打电话报警等等。
这些由一个事件诱发多个其他事件，然后有多个接下来的事件去确定了上一个事件的发生。事件在现实社会中有时是一石激起千层浪，
有时又是石沉大海，杳无音讯。这里的区别就是（有多少人关心此事件，即有多少监听器。

事件的意义有多大，就会传递有多远，同时事件传递的有多远，事件的意义就有多大。）
在设计系统的时候就可以据此设计系统的事件。

好了上面阐述了一些业务与场景，场景与事件的关系及相关的遐想。接下来说说角色和活动。
其实场景中又包含了角色以及角色的活动，角色及角色的活动又伴随着业务。因此业务，事件（事情），场景，角色，活动等又相互交融。
组成了现实的系统。而所有这些又都是并发或者并发的。在单核上是并发，但在集群，在公司，在社会，这些又是并行的。

说了这么多，领域又在哪里呢？领域模型又在哪里呢？其实我认为，领域在各个业务中和各个场景及其活动中。就如同
学校这个场景包含了教师，学生等角色，在课堂，教室等不同的容器中进行着教学活动和教学业务。进行着化学，物理，生物，社会
等不同学科的知识传递，这就是在某个领域里进行活动交流。当然这些领域仅仅是进行领域知识的传递。
但在社会活动中就是利用领域知识进行生产了。比如程序员利用领域知识解决业务问题。把业务利用某些领域知识（编程知识，编程理论）和领域工具（电脑，应用软件）来完成特定领域的编程活动。
然而这个特定的领域就是我们生活中各种场景，各种业务活动。这是多麽的大的一个循环，又是多麽具有层次结构的世界。

从上面的描述来看：领域是融合在业务、事件（应该说是事情，英文里的事件和事情应该表达不是很清楚。所以要注意区别）、场景和
活动中的。

上面说了领域，领域语言，以及模型。那么领域驱动建模和领域模型又是什么关系呢？领域驱动建的模型是领域模型还是一般的通用模型。

再次回到上面的相关时间场景中去，思考一下，其实我们可以发现：领域模型就是我们对事件，事情，场景，角色，成员，活动的描述。
其实领域模型就是模型的集合。同时这些模型也是有意义的模型。有意义的业务模型，事情模型。当然也很有可能是通用的模型。

说了这么多，终于想清楚了。原来领域就如同一个圈子，圈定了一个范围，这个范围内的东西就是该领域的模型实例。通过对这个范围内的模型进行建模，进行有意义的命名（老子的道德经，无名万物之始，有名万物之母）。然后通过各种形式的描述，形成了该领域里的领域语言。其实banq所说的领域具有稳定性，也是有道理的。关键看领域的范围是否稳定，如果领域的范围不变，那么领域的及其相关的领域模型，领域语言就是稳定的。或者是动态稳定的。欢迎大家讨论

[该贴被wldst于2013-01-09 00:18修改过]

[该贴被wldst于2013-01-09 00:20修改过]

SpeedVan

2013-01-09 01:34

正确，学术上和哲学上就是这样的理解。

wldst

2013-01-09 16:04

现在刚刚看完《对领域驱动设计的初步认识》的系列文章，虽然昨天晚上只是看到了一半，就发表了看法，但是还是发现大家在2010年底的关于DDD的认识和我的的理解还是很相近的。特别是SpeedVan,你的很多观点都是我赞同的，比如领域的圈圈问题，领域所包含的内容，领域的动态稳定。我都是赞同的。

flyzb

2013-01-09 22:52

呵呵。。欢迎讨论。
关于对领域相关概念的理解，整体来讲大家都差不多，没有太大区别。而关键在于实际业务中如何去把握领域，从论坛里就能看见每个人认识都不同。
对于中国目前的社会现状来说，我们正处于一个急剧变化的社会中。对于企业而言，有很多东西都比较落后，处于一个大幅度追赶的大背景下。在这样的情况下，我们对业务认识在不断变化，所以我一直再讲“领域模型”的不稳定性，也是我一直不敢真正用聚合根的原因。其实我更关注“业务内聚的合理性”，内聚应该是“自然形成”的，不用那么强调“显性化的聚合根”。只要“业务的聚合”具有单一性，那就没有什么问题。

猜你喜欢