|
该帖已经被评为良好帖
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2011-04-18
sulong 写道 各位，不如把《领域驱动设计》那本书看一看，如果连这一方法学的经典书藉都没有看过，这样讨论没有多大意义。
DDD的好处不仅仅体现在代码上。它要解决的领域与实现的矛盾，不是具体的技术手段。具体的技术手段，就只强调独立的领域层代码，及模型绑定代码。其它的都是一些具体的技巧了。 书是好书，看过也不能代表什么。如果DDD，真的是银弹，我相信肯定早就流行了。它不流行，必要有它的缺点和局限性。 |
| 返回顶楼 | |
|
发表时间：2011-04-18
最后修改：2011-04-18
1.从维护性上看，将业务逻辑集中在Service层更容易实现开闭原则。
2.程序员写的代码要符合架构整体风格。比起所谓的贫血模型和富血模型来看，一会这个风格，一会另一个风格，更不容易维护。如果说Service层复杂，说明业务本身就复杂，或者Service没有分好。 3.至于xml配置和注解配置方式，应该是xml配置更容易维护。注解配置适合快速原型开发，所以我个人觉得做原型的时候用TDD加一套快速开发工具，等真正实现，用更清晰的解耦即可。 |
| 返回顶楼 | |
|
发表时间：2011-04-18
引用 Roo功能目前还不很强大，比如还不能根据配置的数据库链接直接从数据库表来生成Entity，以及前端表示层使用JSP和绑定Spring MVC(基于Spring 3.0支持REST)等，但是这些改进目标已经纳入其roadmap中。说一下另一个框架Seam对于富血也做得不错了，但还不是完全富血，同样也绑带了JSF。
这两天又看了一下spring roo,修正一下观点，新的spring roo版本已经可以用DBRE reverse from db.并且好像也很强大。 1.一个entity只需要写属性就行，get set免。 2.简单的增删改查功能，一键生成。 3.通过aspectJ实现编译时aop，完全不影响性能。 4.可以动态查询：如findPersonByNameAndMinMax(),相当于like name,between min to max这样的功能。 5.用Spring roo实现DDD，只有两层Controller层和Entity层。另外Service层（可选），Dao不推荐用了。 6.jms,email,json序列化支持 7.其它说明：开发需要JDK1.6以上。 8.不想用roo时，可以快速删除annotation和相关的jar包等文件。 ... Spring roo架构overview： 
AspectJ实现编译时AOP 
自动动态查询，自动生成 
|
| 返回顶楼 | |
|
发表时间：2011-04-18
我对DDD也不是十分清楚，不过介绍个网站
http://www.jdon.com/ 这个站长对DDD研究得挺深入的 |
| 返回顶楼 | |
|
发表时间：2011-04-19
kongruxi 写道 我对DDD也不是十分清楚，不过介绍个网站
http://www.jdon.com/ 这个站长对DDD研究得挺深入的 这个网站，也许我比你去得更早，05年的时候经常去。自从robbin和banq开干后，我就慢慢转到javaeye来了。banq是搞ejb出身的，想当然要搞DDD.我那会是从hibernate的潮流。 |
| 返回顶楼 | |
|
发表时间：2011-04-19
itstarting 写道 引用 3.对于简单的软件，使用领域模型，显得有些杀鸡用牛刀了。 我到觉得简单的软件用领域模型更方便点。 +1 同意此观点 |
| 返回顶楼 | |
|
发表时间：2011-04-19
peterwei 写道 fireflyc 写道 哎，看了楼主的介绍我觉得，楼主对领域驱动设计认识似乎是有问题的，而且我感觉基本上很多人都是存在这样的一个误区。
认为service和entity和DAO合并在一起，就是领域驱动了，比如之前是 Student,StudentDAO(或者泛型DAO),StudentService现在只有一个Student来干所有的事情。 我觉得持有这种观点的人是对DDD的理解有问题的，DDD中最为突出的5辆马车，Entity，Value Object，Factory，Service，Repository，这里可是也有entity也有vo，也有service的。只此一例来证明楼主对DDD的理解有偏差。 我承认我对DDD了解不深。那么，DDD应该是吧数据和逻辑放在一起吧？service层应该不管逻辑的事吧，应该只是浅浅的一层。那么dao,service是可有可无吧，从spring roo可以看到一斑。如果你有DDD实践经验，那么你认为DDD在国内是否已经成熟，是否可以在实际的项目中推广了？推广的难度是什么？为什么大家还在用贫血的模式？ 如果将传统贫血中的SERVICE看作 充血模型中的ENTITY那他们有区别是啥？ 认同楼上的观点 充血模型并不一定要去掉DAO service 而是让ENTITY具有它特有 自身行为的放其ENTITY中实现 作为一个对像整体出现 另外一些交互 或是可能会常变动的业务 在SERVICE层去实现 混血儿最靓了 |
| 返回顶楼 | |
|
发表时间：2011-04-19
最后修改：2011-04-19
看不下去了，我来简单地告诉你们什么是ddd。具体的去jdon看看。
ddd就是利用ORM和AOP屏蔽数据库的sql和事务。比如 bool login（userid,password）; { User user = repository.get(User.class,userid); return user.checkpassword(password); } 而不是select * from users where userid=? and password=? 比如学生选课 student.addClass(class){this.classes.put(class);} repository.update(student);//此处级联更新新增的class 而不是insert into classes values(....) 总之，这种代码几乎看不到sql，看不到commit，仿佛一切都在内存的集合里。hibernate的session基本上直接拿来当repository用就好了。 但显然DDD有其适合场景，有些时候性能成为大问题，必须用hql,甚至sql等办法来解决。 |
| 返回顶楼 | |
|
发表时间：2011-04-19
DAO不用还是缺乏远期规划，现在产品就在考虑将异步调用队列，和消息序列化转向nosql，焦点不应总放在orm和dao上，service的厚度就真那么薄吗
service 本身的对象是不太会被序列化，所以不能简单看成充血对象，方法是service的骨架，属性是皮毛，这和域对象特点相反 如果一个项目RAD的部分占了大头，通常都是生命周期会很短的产品，复用的目标就更达不到了 |
| 返回顶楼 | |
|
发表时间：2011-04-19
semmy 写道 我有三点疑问：
1、同样当业务逻辑变得越来越复杂时，富血的领域对象也将变得越来越复杂，难以维护，如何解决？ 2、在领域对象中封装了太多的方法或属性，是否有必要，可见性等等会不会造成更加混乱，如何解决？ 3、还有这样的领域对象是否适合做DTO呢？ 这样理解第二点疑问：
public class clsA{
method1();
method2();
method3();
}
public class clsB{
//需要调用method1，但不能调用method2、method3
}
public class clsC{
//需要调用method2，但不能调用method1
}
1、同样当业务逻辑变得越来越复杂时，富血的领域对象也将变得越来越复杂，难以维护，如何解决？ 2、在领域对象中封装了太多的方法或属性，是否有必要，可见性等等会不会造成更加混乱，如何解决？ 3、还有这样的领域对象是否适合做DTO呢？ 说明你不了解领域对象的划分。一个好的对象系统，被清晰的划分出来后，不会有这些问题。这个很考验BA和Architect. |
| 返回顶楼 | |
