我现在真的很佩服banq，顺便问一个问题

多谢，持续不断学习与应用才是最重要的。

关于DDD和四色模型因为都是对同一种事物进行辨识的不同方法，必然存在同一个事物在DDD和四色原型中有不同的表示方法，只是表达方式不一样，实际是表达的同一个概念。

如果这两个方法都掌握了，自然感觉到类似部分，但是它们不是必然对应的。

暂时删除...
[该贴被yananay于2007年07月05日 10:59修改过]

banq, 附件里是我的一些想法，可以看看吗？
谢谢
xyz.zip
src.zip


attachment:

很不错的案例和心得：

正如你文中引用的obert C. Martin 的一句话：
数据库是实现细节！应该尽可能地推迟考虑数据库。有太多的应用程序之所以和数据库绑定在一起而无法分离，就是因为一开始就把数据库考虑在内了。请记住抽象的定义：本质的部分放大，无关紧要部分的去除。在项目的当前阶段数据库就是无关紧要的；它只不过是一项用来存储和访问数据的技术而已。

我非常同意你通过这个案例试图说明：

优先设计业务层，将数据库层放在后边设计，并不是十分难的，恰恰相反，这种方式对于业务的理解，更加有好处。
对于持久层的设计，无论是采用JDBC，Ibatis，或者Hibernate，总可以找到一个合适的模式来将业务层与之匹配在一起。其实大部分情况是我们一定会知道预先使用什么持久方式，所以，预先设计出一个结合业务与持久的模式，也是必要的方法。

数据库仅仅是持久层的一种解决方案，即使它是目前最广泛使用的持久方案。但是，在设计我们的业务的时候，不要着急去考虑如何创建数据库，先把我们的业务逻辑设计清楚，然后再去考虑哪些类需要持久，才是正确的途径。

我认为在复杂软件系统种，业务逻辑的分析和认识需要排除任何技术细节，不断推入细化，这才是软件系统实现中最关键也是最难的。

我想知道我实现那种lazyload 方式正确吗。。。？

下面这段代码是有些问题，如果按照orderList 来决定是否加载就不行了。

public List getAllExistsOrders(User user) {		
		String userId = user.getUserId();		
		//constructed by sql: select * from orders where user_id= user.userId
		//the object in the list will be Order.java
		List orderList = null; 	
		if(orderList != null) {			
			for(int i = 0, m = orderList.size(); i < m; i++) {				
				Order order = (Order) orderList.get(i);
				//constructed by sql: select * from order_items where 
                                                           //order_id=order.order_id
				//the object in the list will be OrderItem.java
				List orderItemList = null;
				order.setOrderItemList(orderItemList);
			}
		}		
		return orderList;
	}

banq , 你贴的那个代码是非lazyload持久层实现的代码... ...

只看文档，源码没看，你把lazy-load代码贴上来看看。

櫴加载目前我知道有三种解决方式：
1. 2001年得Jive2.5中，在实体对象中设置一个boolean标致load是否执行。
2. Hibernate等框架使用动态代理，只有在使用访问时才通过动态代理load
3. 前面两种都符合DDD，这一种解决方式不是在实体内解决，而是外借服务等操作来进行，我在JiveJdon3中是这么做得。
不知你采取哪种，或者有更好得方式。

[该贴被banq于2007年07月08日 17:11修改过]

在jdon潜水了一段时间，现在是第一张参与。我刚接触DDD，看了LZ给的示例代码有点疑惑，想请教一下各位：
在代码中我看到楼主在service层直接进行持久化操作，持久化操作在DDD中应该是domain model中调用的吧？我不知道是不是我的理解有问题，想请教各位!

进一步问下: 考虑设计一个领域对象的时候,是先考虑有哪些职责还是先考虑有哪些状态?? 我是觉得从状态思考职责容易些,但是想到现在流行的行为驱动开发,我想也许先思考行为更正确一些