DDD领域驱动设计

2013-12-16 17:00 "@ sinaID99267"的内容想求老大进一步用代码的方式来阐述一下这个问题，最好是一个简单易懂的示例，谢谢！ .

BA是业务分析师的意思，但是什么是一个好的业务分析师呢？什么时候你有一个好的分析师，什么时候你又没有了呢？很多项目在一开始就失败了，因为没有完整 一致的或者过于繁琐的分析，由于不正确的项目计划导致项目迈向错误的方向，最终导致项目失败。

前言：我认为，抽象和封装是面向对象编程思想的精华，这在两年前我已经发过这方面的帖子了。现实中，给无OO建模概念的人员直接交流OO建模是何等困难!他们恪守着数据库建模，代码优先的律令，无论我如何强调关注业务本身，对业务抽象，实现业务软件模型和现实世界映射的重要都无济于事。经常发生的现象可能是：我说的理

上文中一个研究结果：受过教育的人都不太能看到自己的偏见，他们更容易妄下结论。这大概就是中国人常说的身在庐山中，不识庐山真面貌。 对业务需求分析时，如何避免盲人摸象的片面和偏见，是BA面临的最大挑战，这是一个思维习惯问题，江山易改，习惯难移啊。

1.帮助你实现DDD聚合设计 如果创建一个对象的属性是通过使用外部服务实现，这是比较容易，没有任何问题。但是，如果该属性是在创建该对象的同一个方法中来创建，那么就有了问题。在这

早在一年前就有听说过jdon，近期又对banq给出的几个例子结合框架（jdonframework）源码读了一下，对于jdon的核心思想->领域驱动建模（Domain Driven Design）有些粗浅的理解。我个人的认识是：1.领域，即业务模型，如banq给过的两个例子：比赛、机器人。这里

Implementing Domain Driven Design中文版《实现领域驱动设计》出版，感谢译者滕云，他是ThoughtWorks的软件工程师，博客地址为www.davenkin.me。点按标题进入.[该贴被banq于2014-04-03 08:08修改过]

Mathias Verraes (@mathiasverraes) 在Qandidate.com 现场进行DDD建模风暴会议图：

如果我给你五十万欧元，你会很高兴。如果我给你一百万欧元，但在回家的路上，你遭受抢劫失去五十万，你会不高兴，即使最终的结果是一样的。在心理学上，这叫做损失厌恶。 也就是说，损失比收益对我们有着更高的影响。我们不是

DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。重点不同导致编程世界观不同。 上面的话摘自：jdon对DDD的解释

Implementing Domain-Driven Design一书的作者vaughn vernon最近在研究用scala和akka来实现DDD，如果有同好，可以一齐关注、学习。https://vaughnvernon.co/?p=770

项目需求得到如下上下文 ： 媒体管理 ／ 论坛 ／ 电子书 这3个都需要用户权限管理，这时候当然最好的是有个rbac系统，但单独开发它很耗时，我就采用了共享内核。这个内核就是 user ，很小，只有一个user aggre

比如，用户有很多种，微博用户有微博nick，getNick，银行用户可能就只有getID，那么在一个系统内部，多个用户聚集在一起，按照聚合根的说法，是由聚合根getUser（）吗？ 那么聚合根里 就会有很多这样的getUser。是否合适？那他跟资源库又有什么分别呢？因为我可以直接从资源

在不同的上下文之间通过事件进行交互，那需要得到返回值的情况下，还叫做事件么？我有些怀疑...因为事件发生就是发生了，其他领域对该事件有何种响应本应该和事件源无关的，但这种需求有确实存在，觉得很矛盾，但如果不使用事件确实又没有其他更好的方式来处理...大家讨论讨论！

求大神终结一下领域驱动开发要点抛砖引玉吧.说一下我理解的1.一个实体对应一张表,实体为一个简单的POJO2.一个聚合根有多个实体,但是一个实体只能被一个聚合根所拥有3.聚合根控制每一个实体的增删改查,4.聚合根封装了业务逻辑(依据系统划分的边界).