DDD仓储

ORM已经不好了，ActiveRecord其实比ORM更坏，因为它隐藏对象其实是数据容器这样的事实，如果说ORM是将真正对象变成数据容器，那么ActiveRecord还隐瞒了这样事实，也就是说，如果说ORM做了偷梁换柱的坏事，ActiveRecord不但做了，还隐瞒自己做的坏事。

Repository模式又称为仓储模式或存储库模式，替代以前的DAO模式: 存储库模式限制我们在应用程序直接使用数据库的数据，并为数据库操作，业务逻辑和应用程序的UI创建新层。 它是软件设计

如果要删除指定标识的实体，是由Respository来操作，还是Entity本身来操作？ 从业务角度来看，入库、出库都需要记录，删除操作自然应该放在Respository。可是Respository并不知道Entity的细节，如何执行删除操作？ <

架构模块正如我们已经指出的那样，大多数DDD系统可能会使用OO范例。因此，我们对领域模型的元素可能很​​熟悉，例如实体，值对象和模块。例如，如果您是Java程序员，那么将DDD实体视

这是来自Node.js路线有关混合两种ORM模式Active Record（活动记录模式）和Data Mapper（数据映射模式）的思考。其实质是引发了失血模型与充血模型的区别，更深层次是引出了掌握DDD的必要性。 首先这两种持久模式的特点如下：A

在我们当前为团队构建SQL Server数据目录的过程中，我们正在优化我们的解耦工程工作。有一些具体的因

理论总是绕口的，特别对我这种懒人。只能说我懒，不能说理论无用。 那么标题“多个domain黑匣论”，简单的来说就是让领域层本身可以分为数个领域，下面以jsdm代码为例（记住：jsdm是nodejs框架还不成熟，能掌控的眼下只能是寡人，呵呵，推荐大家用ban

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

假设Book是一个聚合实体，现在要删除某一个Book没有问题，通过仓储Repository加载实体，然后调用其delete方法即可，但现在问题来了，如果DB中有上万个Book需要一次性批量全部删除，那么应该如何设计呢，看下面的代码：

按照对DDD的理解，一般使用规约模式实现内禀的业务规则。但有些业务规则可以体现为对其他聚合的查询。而对仓储的调用一般都放在应用层，而这样会造成部分业务逻辑散落在应用层。请问大家有没有好的办法处理？ 附上一个订单系统例子，当用户提交订单后，应用层的处

CQRS在设计上由于考虑到领域模型的事件原还，所以需要将大量的Event持久化到EventStore中，这样就需要与数据库打交道，对于Repository的每一个保存操作，一定会与DB有所交互，这使得in-momery由于调用DB而变得不是纯粹的内存操作，这是伪in-memory方式，真正的in-m

现在人们已经认识到Hibernate等ORM有一定的局限性，在CQRS读写分离的架构中，ORM主要用于命令写操作，进行复杂的增删改查CRUD；而SQL用于查询读操作。

如题，仓储是否需要缓存领域对象，即每次从仓储里拿出领域对象都是同一个对象而不是每次都从数据源中构造一个新对象，此处的缓存是指JVM的内存，不是Ehcache或者Memcache等。请大家指教。另外问一下，如果需要缓存的对象里有其他无法缓存的资源怎么办？比如我的领域对象对应现实世界中的一个特殊

借用一下一位DDD朋友论坛中的图：

Hi，各位，我想请问一下，如果一个聚合之内存在一个多重的关系，例如：Resource(1)--->(*)Content其中Resource是聚合根，Content是聚合根内一个实体 如果我需要将持久化的Resource取出这很简单，通过Re

在业务系统中，会使用很多元数据，比如某些论坛注册需要选择国家，总不可能将全世界所有的国家名称和代码都建立成枚举，这种应用一般都是将这些国家建立成数据库端的元数据表，这种元数据映射到系统中肯定是VO，这点是肯定的，而且这种VO可能在多个领域聚合中都有可能引用到，那如何来对这种数据进行加载呢？因为每个仓