领域驱动设计思路.pptVIP

* * 对象和数据库 数据库查询是全局的，可以直接想得到想要的对象，但对象内部的聚合不变性就会被破坏。 对象网是通过对象关联来管理的，但我们不需要把所有对象连接起来。 是使用导航限制连接，然后先找出聚合根，再根据根的限制导航找出结果？还是使用查询，直接查询我们要得到的结果？ Customer与Order，是设计为关联，还是通过CustomerId把Order从数据库中查询筛选出来？ 数据库编程思路 很多开发人员更喜欢使用SQL，对如何从数据库抓取他们想要的对象感兴。 业务逻辑都跑到SQL代码或客户端代码中去，而实体和值对象变成了纯粹数据容器。 大部分数据库访问计数复杂性，如数据库范式，很快使得代码陷入混乱，只好抛开领域层，模型成了摆设。 另外一个极端：加入太多关联，成了蜘蛛网，把模型搞得一团糟。 Repository和查询 不需要为通过导航方法能够获得持久对象提供查询访问，聚合内部对象可以通过根来导航。 值对象无需全局查询获得，比较少见，值对象生命周期很短，属于临时对象，一般通过聚合根获得。 仓储可以实现数据库新增 修改 删除和查询CRUD，仓储可以实现不同标准的各种查询。 Repository定义 为客户端访问某一聚合类对象提供全局访问接口Repository ， Repository主要是在内存中建立一系列的聚合对象。 Repository提供CRUD等通用对象操作方法，把数据库数据存储插入和删除等方法封装起来。但是不插手事务。 提供符合对象方式筛选查询，仅为确实需要直接访问的聚合根提供仓储，其他则不必。 让客户端只关心模型，而不是数据存储。存储和访问都交给Repository完成。 查询仓储Specification 查询存在大量项目，但必须是围绕实体聚合根对象的查询，可以使用专门框架。 引入Specification制定，用来让客户端将它希望获得的查询结果描述出来，也就是制定出来。 输入参数使用Criteria来封装各种查询输入参数，提供Criteria的查询框架比较复杂，如Hibernate的Criteria。 如果聚合中有大数据，可通过懒加载lazy延迟加载，只返回一个代理，使用时，再进行加载。 CRUDTemplate 很多框架都有CRUD模板，在这个模板中，我们使用通用的object来替代领域对象。客户端只要继承这个模板，然后实现特殊多样的查询方法即可。 public void insert(Object o) throws Exception { daoCRUD.insert(o); clearCacheOfItem(); } public void update(Object o) throws Exception { daoCRUD.update(o); clearCacheOfItem(); } public void delete(Object o) throws Exception { daoCRUD.delete(o); clearCacheOfItem(); } public Object loadModelById(Class classz, Serializable Id) throws Exception { return daoCRUD.loadById(classz, Id); } Repository和工厂 区分新创建和构建 第三种模型 服务 将行为放入对象才是真正对象，这样可防止面向过程编程。但是放入不确当行为，会破坏对象的清晰概念。 有些对象侧重于操作动作行为，没有状态，就象四色图中MI，是一种活动事件，这些对象应该被标记为服务。 服务来源现实：加油服务 快递服务，服务不是一个过程化编程的概念。 分应用服务(事务安全)和领域服务。 服务的难点 服务因为处于过程化编程功能类和OO之间，很容易被误用。 误用情况就是：将业务功能使用服务实现，这就造成了贫血失血模型。 如果将所有功能都塞入实体对象，那么实体对象变得非常庞大臃肿，失去灵活性。 对行为方法划分粒度很重要：属于实体本质行为的放入实体；而这个行为跨越了实体本身范围和生命周期的，类似管理协调行为的，可放入服务中。 业务逻辑和服务 不要将业务逻辑写到Service服务，这样会造成模型失血，只有属性没有业务行为。 将业务行为放入领域层，不一定放在实体类里实现，可以做实体类代理或Specification规则。 通过服务来激活业务行为与将业务行为代码放入服务是有本质区别的。 增删改查CRUD是服务吗？ CRUD是数据库的概念，我们要转换成对象概念，详细情况详细研究。 增：新增新对象，并持久化保存。这类似管理工作，可放入服务。 删：删除一个存在对象，并从数据库记录删除，也是管理，可放入服务。 改：对象内容修改，要根据修改类型来划