DDD领域驱动设计 - 第37页

不变性是统领业务分析和高性能架构重要法门，通过业务上不变性分析设计，可以实现代码运行的并发高性能和高扩展性。不可变性是一种抽象，它并不在自然界中存在，世界是可变的，持续不断变化。所以数据结构是可变的，他们是描述真实世界某段时间内的状态。而状态经常会被修改

1. 创建领域对象采用构造函数或者工厂，如果用工厂时需要依赖于领域服务或仓储，则通过构造函数注入到工厂；2. 一个聚合是由一些列相联的Entity和Value Object组成，一个聚合有一个聚合根，聚合根是Entity，整个聚合被看成是一个数据修改的单元，也就是说整个聚合内的所有对象要么同

现在很沮丧啊。。。前段时间负责的项目，雄赳赳的采用领域对象的方式来建模和编写。将系统分成： controller > 粗粒度service > context > repository > dao 这几层来进行开发，同时，借鉴 dci的架构将bo的行为移到了role中。

1. 聚合根之间能相互引用吗？2. 聚合根之间如果相互引用了，则会造成一个可怕的后果，那就是：很容易导致取出一个聚合时会级联取出很多直接或间接引用到的其他聚合根，到最后可能会取出整个对象树；3. 那聚合根与聚合根之间就不应该相互引用了吗？我的建议是：是的。但是可以只存储引用聚合根的I

最近看了www.domaindrivendesign.org网站上的一篇关于如何设计聚合的文章，受益良多，让我对DDD中的

我是一个初学者，以前一直在写程序，是的，说实话，我发现我没有遇到过一家公司是按照面向对象的建模来进行的(前期分析设计)，都是采用数据库建模来进行设计的，我看了很多关于'领域驱动设计"的文章，我发现有些话，说了跟没有说是一回事（我没有别的意思）。我看了下的感觉，就是要对你所开发软件的行业进行

最近又重温了领域驱动设计的原著，有了一些新的理解。现在我觉得我能更好地理解jdon007之前说的下面这段话了。 “用户需求”不能等同于“用户”，捕捉“用户心中的模型”也不能等同于“以用户为核心设计领域模型”。《老子》书中有个观点：有之以为利，无之以为用。

首先，我觉得软件是用来被用户使用的，也就是说软件是用来帮用户完成一些事情的。从下面的用例图可以很好的理解用户与软件的关系：

这是MF站点的一篇新文章：MemoryImage内存映像，主要说明我们以后要改变过去和数据库打交道方式，直接和内存中领域模型打交道。鉴于

如果domain不能访问dao，来获取数据，那么很多业务方法无法实现啊。这时在将业务方法移动到service层，那不是很失败？如果domain需要访问数据，那岂不是依赖dao层了？

这是一篇领域驱动设计Domain-Driven Design的简要总结：What I have learned a

最近研究DDD开发，遇到一些问题，忘大虾指点，不要只限与概念，最好能有个具体Solution 1.实际项目中许多Entity都引用了User,以往开发的时候，我都只是做了UserID属性来隐含关联。如果有需求对Entity引用的User通过DisplayN

通用业务逻辑的提取有没有必要呢？我说的不是验证、权限、UI，而是领域业务中的业务逻辑。

场景是这样的，现在有一个Tag服务，Tag(标签)跟Content(内容)间是多对多关系，请问Content可以做为聚合根吗，如果作为聚合根实体定义如下是否合理：

我在一个软件公司，由于需求膨胀太快，公司将大量功能进行外包并以此为发展趋势，这其中最大的问题就是外包软件质量无法保证。我在进行这样一种尝试，本部进行需求及领域建模以及模型层（领域层）的实现，提供核心的领域模型的实现及相关文档，只对外围功能进行外包。但当着手时，发现有一系列问题，首当其冲的是项

我自从知道了这个论坛后，我一直在学习关于这个内存领域+事件驱动，我能力有限，很多研究不通，望各位朋友指点迷津，我到现在也是非常的困惑，不知道是怎么回事，感觉想做梦一样，也不知道明白，内存领域，说的是让一切在内存中跑起来，通过注解来进行标示。。。。。我其实想清楚的就是这个整个架构，一个完整

我想做过产品的都免不了涉及这个问题吧，但是网上这方面的资料确几乎没有，哪位分享一下，或分享下链接也行。