实现领域驱动设计 笔记

20140715-implement-DDD-notes.txt

实现领域驱动设计
跳转至： 导航、 搜索
目录

    1 DDD入门
    2 领域、子域和绑定/限定上下文（Bounded Context）
    3 上下文映射
    4 架构
    5 实体
    6 值对象
    7 领域服务
    8 领域事件
    9 模块
    10 聚合
    11 工厂
    12 资源库
    13 集成绑定上下文
    14 应用程序
    15 附录A 聚合与事件源：A+ES

DDD入门
领域、子域和绑定/限定上下文（Bounded Context）

    p38 零售商的领域可以分为4个主要的子域：产品目录、订单、发票（Invoicing）、物流/运输
        注：DDD中的子域不仅仅意味着单独的模块，它还暗含了可在分布式环境下以SOA方式部署、在实际业务运营中外包出去？ 
    p55 考虑一个图书出版机构，它需要处理图书生命周期的不同阶段，可以认为对应不同的上下文
        概念设计，计划出书
        联系作者，签订合同
        管理图书的编辑过程
        设计图书布局，包括插图
        *将图书翻译成其他语言
        出版纸质书或电子版
        市场营销
        将图书卖给销售商或直接卖给读者
        将图书发送给销售商或直接卖给读者 
        在每个阶段中，“图书（Book）”都有不同的含义（！！！） 
    p60 为了分配任务在拆分上下文是一种错误的建模方式（～按AOP分解？）
    p62 这里的共享内核其实就是不同上下文使用到的公共代码？
    图2.7 DDD领域：敏捷项目管理上下文＋协作上下文＋身份与访问上下文 

上下文映射
架构

    分层及DIP（依赖反转）
    六边形架构（端口与适配器）
    p113 JAX-RS并不重要，我们可以用Restfulie/Node.js来完成相同的功能
    SOA服务设计原则：
        服务契约
        松耦合
        服务抽象（隐藏内部实现逻辑！）
        服务重用
        服务自治性（？）
        服务无状态性（批注：REST就是无状态的）
        服务可发现形（服务的发现查找本身也是服务！）
        服务组合 
    REST
    CQRS（命令和查询职责分离）——这让我想到了Web编程中的POST重定向GET的编程模式～
        p124 为安全性考虑为不同的角色创建分离的数据库视图（为什么只是视图？单独的表我看也没问题啊）
        ＊处理具有最终一致性的查询模型：加上版本化的时间戳标签？ 
    EDA（事件驱动的架构） 

实体

    p156 生成唯一标识：java.util.UUID.randomUUID().toString() 

值对象
领域服务
领域事件
模块
聚合

    p314 我们的思维被一些错误的不变条件所占据，而不是真正的业务规则。这些（错误的不变条件）只是开发者人工引入的约束而已
    ... 我们主要关注的是聚合的一致性边界
    p323 如果你试图在单个事务中修改多个聚合，这往往意味着此时的一致性边界是错误的
    p324 仅仅使用ProductId属性作为关联，而不是Product对象类型，节省了加载时间和内存（延迟加载）
        缺点：在UI上组装多个聚合予以显示变得困难 --> ？可考虑theta联合查询或CQRS 
    ＊原则：在边界之外使用最终一致性
        事务一致性 or 最终一致性？ 

工厂
资源库

    p377 TopLink同时提供了Session和Unit of Work
    面向持久化资源库
        HashMap#put/get
        Gemfire / Coherence / MongoDB / Riak？ 

集成绑定上下文

    filteredDispatch() ？
    p435 如何避免无序抵达/多次投递的消息通知造成的问题？（有条件的谓词）
        动作执行的前提条件约束通常使得实现幂等操作成为可能 

应用程序
附录A 聚合与事件源：A+ES

    事件流、事件存储、append-only