我还是有点不理解面向对象比面向过程的可维护性强，强在哪儿了。用面向过程，在service里做一些操作。面向对象，在对象里做操作，然后在领域服务里在调用对象的各种操作。要是需求变了，面向过程就是在ser.

我在我们的项目中引入了ddd的分析方式，可能有点粗略，但是我尽量往ddd靠近，有几点迷惑：1.统一语言：我们掌握需求信息，根据获取的用户需求列表来分析业务；根据我们的经验来抽取统一语言；我们使用统一语.

大家好，现在我有点不太明白领域模型与服务的问题，领域模型是不是应该有行为，也就是说应该有的职责与业务逻辑，那么服务是做什么的呢，做事务和调用仓储么。还有业务逻辑与领域逻辑是一回事情么。现在觉得服务层有.

现在做一个系统，框架就用spring 打算这样分层dao:只负责数据的持久化以及查询cache： 领域对象存放的地方repository：数据的入口与出口，负责保存数据到cache，根据需要来持久化数.

应用容器总是会提供一系列的服务，而这些服务还是可以容器自管理的，省事方便，通常也是采用横切的方法插入业务方法，那这样的话在应用容器托管一类的应用里AOP还会用到吗？我的理解是AOP跟Spring一伙，.

一直也对JAVA EE层次架构非常感兴趣，用SSH开发居多，对于DDD的概念，真的没有听说过，看了大家很多的文章，也看不明白，或者真的要静下心来，买本书来好好学习学习。 我的理解是分层的层次.

现在项目出现了个很大的问题，由于经验不足，想请教各位这个项目的架构（其实不能算是架构），是按一个开源的电子商务示例来组织代码的，分了几个层：commondomain（领域对象）persistence(.

DDD一书中说：服务其实有两种服务,一是领域层服务;二是应用层服务.他们的不同点是:应用层上的服务没有任何业务含义,领域层的服务包括了基本的业务逻辑。一下引用banq老师在（对JiveJdon3中se.

今天写代码的时候，突然发现有一个service只是在传递action的调用到dao中，然后返回dao的执行结果到action中，其中service并没有其它业务逻辑。觉得这个service是不是冗余了.

领域设计里需要从上到下设计所有业务行为的对象以及操作这些对象的接口,但是就算开始的需求分析十分详细,也会有后来客户提出修改或增加新的动作的时候,这时候就要扩展现有的接口,接口下的实现类都要跟着一起改,.

在业务层的Service中,比如我有两个Entity,Entity1和Entity2,那么我有两个对应的Service,Entity1ervice和Entity2Service.如果有些业务过程要涉及.

我看了其他社区的关于domain model的讨论, 也就是关于Object, ObjectManager, ObjectDAO由于对business logic 和 domain logic的不同处.

按照DDD的思想，我对我的项目也设计了Service层，但对Service层还没有详细的划分，可能我的应用还没有达到很复杂的程度，等有时间banq大哥给讲讲如何对Service再分层。这里遇到一个问题.

先说下我最近做的一个小的人力资源管理系统。数据库都是用 Dao访问的，负责返回一些 pojo,我的pojo 都是和数据库表或者视图对应的，Dao 负责把结果集包装为pojo。Service层，我基本都.