.net关于领域驱动设计

如题,最近看了下领域驱动设计但是还是不怎么明白,想请教下什么是领域驱动设计,为什么要用领域驱动设计,具体会运用到哪些技术,领域驱动设计有什么好处,是易维护扩展还是其它的,研究过的兄弟请给个简单的例子,谢谢!!!

13 个解决方案

#1

有所了解，但没深入，就不丢人了……

#2

领域驱动里面有一条很重要的就是要有领域专家，没有领域专家，领域驱动就是个四不像

#3

引用 2 楼 starfd 的回复:

领域驱动里面有一条很重要的就是要有领域专家，没有领域专家，领域驱动就是个四不像

领域专家,指的什么呢,能不能具体点,具体的都用了些什么技术

#4

领域模型是个很装逼的词，其实就是“高内聚”的一种实践方法，并不是什么新鲜玩意。不过，领域模型的一些方法很有用，可以有效地帮你把一些原先停留在概念层面的东西落地，还是很值得学习的。

#5

从字面上一般人不太容易直接地理解什么叫领域，因为少了两个关键的但很土气的字叫“业务”，这是“领域模型”装逼之所在了。

举个例子吧，大家都知道出入库业务，但很少有程序员能够把出入库理解成两个或更多个领域。哪怕是最小的出入库业务，也包含了记账和搬运操作两个领域。这个概念在一个合格的财务或者库管那里一点问题都不会有，但在程序员那里，就呵呵了。
为什么会出现如此大的偏差呢？原因很简单，程序员不懂业务，而财务或库管描述这两个业务的时候总把他们作为一个业务来描述。于是可怜的程序员就杯具了，怎么做都做不对。

#6

学习了！！！！！！！

#7

引用 5 楼 xuanbg 的回复:

从字面上一般人不太容易直接地理解什么叫领域，因为少了两个关键的但很土气的字叫“业务”，这是“领域模型”装逼之所在了。

举个例子吧，大家都知道出入库业务，但很少有程序员能够把出入库理解成两个或更多个领域。哪怕是最小的出入库业务，也包含了记账和搬运操作两个领域。这个概念在一个合格的财务或者库管那里一点问题都不会有，但在程序员那里，就呵呵了。
为什么会出现如此大的偏差呢？原因很简单，程序员不懂业务，而财务或库管描述这两个业务的时候总把他们作为一个业务来描述。于是可怜的程序员就杯具了，怎么做都做不对。

请教下,比如我现在一个"门禁卡机表实体",实体名字就叫MachineInfo,实体里有些属性:卡机名称(MachineName),卡机IP(MachineIP),卡机地址(MachineAdd)等等,那么我这个实体可不可以视为一个领域模型呢?这个卡机实体类里还有一些对卡机操作的方法,比如"连接卡机","向卡机写入人员权限","设定卡机时间"等等主法,像这种设计可不可以理解为是"领域驱动设计"呢?

#8

如果"门禁卡机表"纯粹是考勤记录的话，你可以把它看作是门禁系统的一个组成部分。读取打卡记录、获取考勤记录（加工过的每天签到签退记录）、连接卡机、写入权限等方法作为考勤类的成员方法的设计，毫无疑问是面向领域的设计。

#9

是 一种 分析需求的思维或方法论

如同 
面向过程 面向对象  面向用例 领域驱动

因为是思维和方法 不是一两句话可以说清楚的

我不知道你看的是什么，也许看到东西还不够

可以看看Thinking in UML 这是讲面向用例的分析方法，第二版有提到 领域驱动
你对比一下两者 也许会有所得

#10

不要没事老玩弄一些 概念,这样永远也不落地

不要以为建了个什么类,就是 模型了

模型也不过是个概念,并不是某个具体的东西

#11

所谓架构,所谓模型,所谓模式,都是一些概念

可能你做的整个工程,就可以看做是一个模型,也可能你封装了一些代码,可以看做一个模型

模型这个概念就和 封装一样

到底是封装成方法,还是类,还是类库工程,其实范围是不一样的,但是我们都把它叫封装.

而你建一个 模型,它到底包含多大的范围,是整个业务还是业务的一部分,这都是抽象的概念,没有确定答案的

#12

引用 7 楼 david_88888 的回复:

请教下,比如我现在一个"门禁卡机表实体",实体名字就叫MachineInfo,实体里有些属性:卡机名称(MachineName),卡机IP(MachineIP),卡机地址(MachineAdd)等等,那么我这个实体可不可以视为一个领域模型呢?这个卡机实体类里还有一些对卡机操作的方法,比如"连接卡机","向卡机写入人员权限","设定卡机时间"等等主法,像这种设计可不可以理解为是"领域驱动设计"呢?

没有领域驱动的名词儿，你的设计也是可以“视为一个领域模型”的。因为你本来就是基于业务领域模型来设计试题模型的。

《领域驱动设计》那本书是个拼凑之作，在工程技术上的含量其实不高，而是收集了很多需求分析和模块设计概念理论，加以整理。看看，对其概念有所利用，也就算了。

#13

因为你本来就是基于业务领域模型来设计试题模型的  -->   因为你本来就是基于业务领域模型来设计实体模型的

最近的机器不熟悉我，只能选词总是出错。

许多工程技术，是有着一种技术著作的独特风格的。而Eric等写的类似《领域驱动设计》之类的书，很杂，表面上看是OOAD最初级的读物，而内容就像管理类书籍一样崇尚非常繁琐、缓慢地进行地自顶向下分解式的。就好像你去听一场高级的技术讲座，别人都能在40分钟内讲出好几个特别厉害的框架，而有个别人（主要是女人）则是从顶层开始一点点、一圈圈地反复循环扫过各种概念，用了70分钟虎头蛇尾地讲完了，最后你发现好像什么都讲到过了、又没有什么可操作性。就是这种风格。