• 按照DDD的思想，我对我的项目也设计了Service层，但对Service层还没有详细的划分，可能我的应用还没有达到很复杂的程度，等有时间banq大哥给讲讲如何对Service再分层。 这里遇到一个问题，就是我在一个Service A里写的一些业务处理代码
  • 现在后台分成如下几个层：Domain：提供getter/setterDao：接口，定义了持久化方法，CRUDDaoImpl：Dao的实现Service：业务逻辑 但是在实际的过程中发现，service里面有很多涉及到持久化的
  • 我们知道，在领域设计中，划分为三种模型，分别为：实体(Entity)、值对象(Value Object)、和服务(Service)。其中Service与我们传统设计中的Service有什么不同呢？ 让我们来回忆一下，通常我们针对将读写xml、资金转账等代码 icon
  • 在业务层的Service中,比如我有两个Entity,Entity1和Entity2,那么我有两个对应的Service,Entity1ervice和Entity2Service.如果有些业务过程要涉及到两个或者多个Entity,那这些业务过程写在哪里?再建个Entity1Entity2Service icon
  • 领域设计里需要从上到下设计所有业务行为的对象以及操作这些对象的接口,但是就算开始的需求分析十分详细,也会有后来客户提出修改或增加新的动作的时候,这时候就要扩展现有的接口,接口下的实现类都要跟着一起改,一旦实现类过多,修改接口将是一个巨大的工程,那怎样才能实现一个有优良扩展性的接口呢? icon
  • DDD一书中说：服务其实有两种服务,一是领域层服务;二是应用层服务.他们的不同点是:应用层上的服务没有任何业务含义,领域层的服务包括了基本的业务逻辑。一下引用banq老师在（对JiveJdon3中services设计的疑问）http://www.jdon.com/article/33948. icon
  • 我看了其他社区的关于domain model的讨论, 也就是关于Object, ObjectManager, ObjectDAO由于对business logic 和 domain logic的不同处理而得到的不同模型， 具体：http://www.javaeye.com/topic/117 icon
  • 业务服务的提供者有可能是本地的，也有可能是远程的，那么应用相关的逻辑应该封装在什么地方更好呢？ icon
  • 先说下我最近做的一个小的人力资源管理系统。数据库都是用 Dao访问的，负责返回一些 pojo,我的pojo 都是和数据库表或者视图对应的，Dao 负责把结果集包装为pojo。Service层，我基本都是把Dao 层重新包装了一下，当然可能是我的系统比较简单哦，每个pojo对应一个Se icon
  • 今天写代码的时候，突然发现有一个service只是在传递action的调用到dao中，然后返回dao的执行结果到action中，其中service并没有其它业务逻辑。觉得这个service是不是冗余了？如果去掉该service，并不影响这个功能的实现，可是如果去掉了，它就破坏了代码的结构，编程act icon