DDD领域服务

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

发帖功能为什么不属于DDD的业务？

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

我在我们的项目中引入了ddd的分析方式，可能有点粗略，但是我尽量往ddd靠近，有几点迷惑：1.统一语言：我们掌握需求信息，根据获取的用户需求列表来分析业务；根据我们的经验来抽取统一语言；我们使用统一语言来建模，实现对象之间的关联关系，但是最大问题是，我们确定的这个统一语言是在变化的，尤其是跟

一直也对JAVA EE层次架构非常感兴趣，用SSH开发居多，对于DDD的概念，真的没有听说过，看了大家很多的文章，也看不明白，或者真的要静下心来，买本书来好好学习学习。 我的理解是分层的层次有：表示层+业务逻辑层+数据库访问层， 表示层对于于MVC模型，struts1.x中的JSP

要实现一个像svn版本同步功能的信息同步模块。 在项目中有User用户信息，由于可能用 pc android IOS等客户端登录到服务器来同步User信息。User用户信息产生不一致的情况主要是 同一个公司的人员都能修改User信息，所以有一次修改以后下一

各位大大，当业务功能涉及到多个聚合的时候，有多种方式进行处理，其中有两种方式使用比较普遍，一种是领域服务，另一种是领域事件，也不排除两种同时存在的情况，那如何取舍呢？ 一个系统中很多业务功能都会涉及到2个或多个聚合，如果使用领域服务，将会导致在领域层会存在大量的领域服务类，这种方式

比如一个模型中，有一个方法，就拿注册来说吧，注册需要判断用户名是否重复，这个判断肯定需要查询数据库了，那么这个在模型中如何实现呢，还有一些类似需要查询数据库字典表的数据来判断是否走下面的代码，这些类似的查询在模型中，应该怎么实现呢？？

DCI的从角色职责和场景的角度来理解业务感觉不容易，问几个问题？ 1、就我理解，上下文是其着承上启下的作用，每个业务过程的一系列行为都想象出一个特定的上下文，实践中是不是很困难？ 2、所有的业务交互行为都要发生在一定上下文（

应用容器总是会提供一系列的服务，而这些服务还是可以容器自管理的，省事方便，通常也是采用横切的方法插入业务方法，那这样的话在应用容器托管一类的应用里AOP还会用到吗？我的理解是AOP跟Spring一伙，都是为了让应用减肥，AOP就算是轻量级的服务插件吧，AOP是非分布式一类的应用里的“服务”实现技术。

大家好，现在我有点不太明白领域模型与服务的问题，领域模型是不是应该有行为，也就是说应该有的职责与业务逻辑，那么服务是做什么的呢，做事务和调用仓储么。还有业务逻辑与领域逻辑是一回事情么。现在觉得服务层有点多余，实在不清楚他负责什么，可领域模型有不能注入仓储类似其他东西，都要用Domain Event进

Banq大哥认为用场景可以代替DDD的Service，我认为也是的；同时，我也认为角色的交互方法可以。由于Service是静态的，也由于历史原因，我们现在要把Service挖出来，变成两种方式来表达。当然我们既然要代替DDD Service必然不能认为这个就是那个的“变身”，因为是突破性的，

信息发布的DDD设计分析： 需要的实体类 Info 信息 User 用户 Approver 帖子审查员

在论坛转了一圈，领域服务大概的意思是说：一些行为放在A模型也不好，放在B模型也不好的，就作为领域服务，也就是说领域服务是夸模型夸聚合的一些行为，那么这些服务有没有状态的，是不是跟application一样也是没有状态的呢，那么可以实现成静态方法吗，还有就是类似一些查询方法算不算领域服务呢，在实践中，

假设系统需要分模块，其中有模块userInfoManager（负责customer的相关信息,prepaidCard ,customerCc,customerNotification等等） 方式一：(实现注册)userInfoManager（里面包