DDD
领域驱动设计 - Domain Design Driven
最后更新于
领域驱动设计 - Domain Design Driven
最后更新于
内层是核心层
Domain Entity和数据库表没有直接关系，更不是一一对应关系
找到DDD战略设计图明确所在上下文，识别新加入的领域对象，看是否有新的上下文产生
对应分层结构找到对应的实现层，需要遵守现有分层结构。因为目前的分层结构可以解决大部分问题，特殊问题特殊讨论
DIP依赖倒置，谁提供服务谁提供接口说明。参照六边型理解现有分层架构，Adapter -> Application -> Domain，
Domain层为最内层：
核心域：是当前产品的差异化竞争力，是整个业务的核心价值所在。需要投入最优势的资源，持久维护高质量的设计
支撑域：重要性不如核心域，但具备强烈的个性化需求，难以在业内找到现成的解决方案，需要专门的团队定制开发
通用域：解决方案业内常见，可通过购买或进行修改得到满足
再看我们的业务需求：通过用户给出的站点列表，根据实际用户合法访问组织机构访问权限，过滤得出用户实际可访问站点列表
结合业内实践，如AWS IAM(Identity and Access management):
可以看出根据不同的维度，如资源维度，我们可以定义资源级别的访问策略，然后映射到对应的账号上面，这样就可以方便我们进行授权管理了。
当请求来到时，认证和授权管理流程如下： 1. 认证，判断用户是否是合法用户，不是则直接结束，是则继续以下流程 2. 授权，结合用户已有的合法权限，对用户将要访问的信息进行合法性审查。合法则继续，非法则拒绝 3. 提供资源服务
按需求，基于现有流程，优化建议如下：
用户交互页面：只展示当前用户可访问资源列表，不给用户造成困扰 - 为什么选了又没出来？
授权中心把关：当请求来到授权中心时，直接拒绝越权访问
基于通用域特性，统一管理资源管理诉求，提供统一服务
DDD与传统设计方法相比，最明显的优势就是打通了全软件设计流程，统一语言，将业务需求以业务语言进行建模和管理。
当出现Data Transfer Object - Domain Entity - Persistent Object间一日游情况时，通常会出现以下场景：
将资源进行了持久化存储，这时领域层只是定义了仓储接口，并简单调用了存储操作
触发了业务逻辑，通过领域命令生产了领域事件，这时会触发其它的业务逻辑操作
如果只是做了第一件事情，并且Data Transfer Object、Domain Entity、Persistent Object这三个对象都很复杂时，对象间相互 转换的成本很高时，似乎有点大材小用的感觉。但其实这背后演生出的问题更值得我们思考：
为什么DTO会这么复杂？它所承载的业务逻辑是不是过于庞大，是否可以进一步拆分？
DDD就是用来对复杂业务进行管理和建模的方法实践。如果出现了过于庞大的DTO，是否意味着这只是个数据集，而不是对应的业务对象。
如果只是对资源进行CRUD操作，那还有什么设计更适合对资源进行管理？
RESTful是针对资源管理提出的设计理论，DTO是否代表了资源对象的集合？如果只是针对资源的持久化，是否可以交给RESTful
是否可以将资源和业务操作分离处理？
DDD根据业务抽象出对应业务模型，强项在于业务command消化和处理，query则是其需要辅助的地方。对应的 CQRS(Command Query Responsibility Segregation)读写分离架构理念就是对这一问题的标准答案。
小结：
资源操作可交由RESTful处理
业务逻辑承载，非DDD莫属
查询需辅助，CQRS为你保驾护行
Data Transfer Object - Domain Entity
采用Domain Factory模式封闭领域对象构建复杂度
Domain Entity - Persistent Object
借助Mapper或Converter模式统一行为，方便使用，减少管理复杂度
