关于DDD最基本的一些知识的请教

VincentLiu
对于一个工作经验很少的菜鸟来说, 使用DDD的设计方式时总是在设计的同时考虑着如何实现, 本来是架构设计, 比较高层的那种, 但却无法割舍细枝末节, 于是设计的东西就变成了伪OO, 最后还是围绕数据库, 围绕表示层来实现整个工程. 所以我想通过一些比较简单的例子, 请教banq等各位前辈如何思考和设计. 我经验少, 也许会问一些比较幼稚的问题, 您可以指给我要看哪一些资料, 我自己去学就行了. (我.net用得比较多, java则较少, 所以很多java的知识什么的很生疏, 也不知从何看起)
问题一: 以人事管理系统为例, person和company当然是Entity, 可是对于属性特别多的person该如何设计呢?? 比如政府系统的人事管理,一个person类有几十个信息集(个人基本信息, 职务信息, 学历信息...), 每个信息集有许多信息项, 一个person类的实例会很大, 当查询时(人事系统非常常用的功能)需要返回一个person的集合, 可能是几万人, 这时的面象对象的设计该如何进行呢?? 我查询可能只需要person的某些信息, 不需要实例化它的每一个信息啊, 如果用SQL语句会很快, 但如果用面象对象会占用太多的资源.
问题二: 人事系统在信息录入时需要维护person的信息, 而后更多的功能是查询和统计, 侧重的是person集合的某个侧面的信息, Repositories中缓存这些person或者person集合的信息感觉用处不大(查询是可订制的, 过于多样与复杂了, 命中率太低), 这时的Repositories该缓存什么呢?? 或许问题一解决了, 问题二也会迎刃而解.
还有很多问题, 暂时就问最最基本的. 谢谢!!
ITfuture 2008-11-03 21:17
提点小意见。顺便锻炼下自己的思维能力。
我觉得你可以效仿HIBERNATE的懒加载模式，当你需要这些信息的时候在去LOAD他的信息。 比如ITERATOR模式。
在比如你说PERSON里属性非常多.你可以将其统一于某一概念的值对象。 在需要这些数据的时候在去仓储中获得。由于PERSON和他的值对象是聚合关系。可以通过聚合根PERSON来访问这些。。。

在我经历的开发中，一般对于人员的操作（曾删改查）是很少。
只是管理员在维护时采用。我觉得如果没有必要不必去非要在仓储中实现缓存。
今天又学了点DDD的东西。感觉思想上面促进很多。所以拿出来说说。有不对的地方。希望大家指正。

banq 2008-11-04 09:45
>一个person类有几十个信息集(个人基本信息, 职务信息, 学历信息...)

ddd其实就是OO，所以，OO分离封装原则要时刻注意，融化到血液的。

一个类如果被设计庞大，肯定是有问题，怎么能将那么多信息都集中到一个person类中，设计模式在这个时候就派上用场，代理桥模式等等都是常用的方式。

所以，DDD不是一个具体的方法学，是一个集大成者，需要有设计模式 以及线程领域的不变性和可变性等等概念。

VincentLiu 2008-11-04 22:31
当遇到两个方向上纵横交错的变化时，可以使用Bridge模式; Proxy模式是增加一个中间层. 可我实在是想不出怎么使用这些方法来解决我这个问题.
需求决定了person的确有很多的信息(基本信息 行政 专业 职级 学历 学位 培训......非常多), 关键问题在于我并不是每次都需要这么多信息, 同时我进行查询或统计等操作时需要的信息又不确定, 导致这个类实在有点棘手.
ITfuture 所说的懒加载确实是一种思路, 可是真的让我将这个类设计这么大么. 有时我需要的是基本信息集中的几项, 行政信息集中几项, 等等, 如果这样加载是否要将整个信息集都加载上呢?? 我觉得不好控制... 我实在没什么思路, 你可以说的详细点么??
我面对的是一个人的信息, 或者是一群人在某些方面的信息, 是不是我该对这些信息进行抽象呢?? 请大家多多指教!!
banq 2008-11-05 09:05
>person的确有很多的信息
你还是没有理解模式真谛，模式结构模式是根据设计目的创造一些凭空无故的类，针对你这个情况，你可以将“基本信息 行政 专业 职级 学历 学位 培训”分别包装成不同对象，你既然可以用不同名词来划分它们，那它们就是可分的。

DDD也指出不变性和可变性，也就是将经常变化的信息和不经常变换的信息分别开来，以便后来业务操作，也便于lazy懒加载这些技术能够施展开，对症下药。