DDD

领域驱动设计 - Domain Design Driven

DDD重要设计指导概念

  • 内层是核心层

  • Domain Entity和数据库表没有直接关系，更不是一一对应关系

DDD设计思路

  1. 找到DDD战略设计图明确所在上下文，识别新加入的领域对象，看是否有新的上下文产生

  2. 对应分层结构找到对应的实现层，需要遵守现有分层结构。因为目前的分层结构可以解决大部分问题，特殊问题特殊讨论

  3. DIP依赖倒置，谁提供服务谁提供接口说明。参照六边型理解现有分层架构，Adapter -> Application -> Domain，

    Domain层为最内层：

Authentication & Authorization 是不是一个独立的通用域

  • 核心域：是当前产品的差异化竞争力，是整个业务的核心价值所在。需要投入最优势的资源，持久维护高质量的设计

  • 支撑域：重要性不如核心域，但具备强烈的个性化需求，难以在业内找到现成的解决方案，需要专门的团队定制开发

  • 通用域：解决方案业内常见，可通过购买或进行修改得到满足

再看我们的业务需求：通过用户给出的站点列表，根据实际用户合法访问组织机构访问权限，过滤得出用户实际可访问站点列表

结合业内实践，如AWS IAM(Identity and Access management):

您可以针对不同资源向不同人员授予不同权限。例如，您可以允许某些用户完全访问 
Amazon Elastic Compute Cloud (Amazon EC2)、
Amazon Simple Storage Service (Amazon S3)、
Amazon DynamoDB、Amazon Redshift 和其他 AWS 服务。
对于另一些用户，您可以允许仅针对某些 S3 存储桶的只读访问权限，或是仅管理某些 EC2 实例的权限，
或是访问您的账单信息但无法访问任何其他内容的权限。

架构图：AWS IAM Architecture

可以看出根据不同的维度，如资源维度，我们可以定义资源级别的访问策略，然后映射到对应的账号上面，这样就可以方便我们进行授权管理了。

当请求来到时，认证和授权管理流程如下： 1. 认证，判断用户是否是合法用户，不是则直接结束，是则继续以下流程 2. 授权，结合用户已有的合法权限，对用户将要访问的信息进行合法性审查。合法则继续，非法则拒绝 3. 提供资源服务

按需求，基于现有流程，优化建议如下：

  • 用户交互页面：只展示当前用户可访问资源列表，不给用户造成困扰 - 为什么选了又没出来？

  • 授权中心把关：当请求来到授权中心时，直接拒绝越权访问

  • 基于通用域特性，统一管理资源管理诉求，提供统一服务

DTO完全透传到Domain层，再由PO原封不动的转出说明了什么？

DDD与传统设计方法相比，最明显的优势就是打通了全软件设计流程，统一语言，将业务需求以业务语言进行建模和管理。

当出现Data Transfer Object - Domain Entity - Persistent Object间一日游情况时，通常会出现以下场景：

  1. 将资源进行了持久化存储，这时领域层只是定义了仓储接口，并简单调用了存储操作

  2. 触发了业务逻辑，通过领域命令生产了领域事件，这时会触发其它的业务逻辑操作

如果只是做了第一件事情，并且Data Transfer Object、Domain Entity、Persistent Object这三个对象都很复杂时，对象间相互 转换的成本很高时，似乎有点大材小用的感觉。但其实这背后演生出的问题更值得我们思考：

  • 为什么DTO会这么复杂？它所承载的业务逻辑是不是过于庞大，是否可以进一步拆分？

DDD就是用来对复杂业务进行管理和建模的方法实践。如果出现了过于庞大的DTO，是否意味着这只是个数据集，而不是对应的业务对象。

  • 如果只是对资源进行CRUD操作，那还有什么设计更适合对资源进行管理？

RESTful是针对资源管理提出的设计理论，DTO是否代表了资源对象的集合？如果只是针对资源的持久化，是否可以交给RESTful

  • 是否可以将资源和业务操作分离处理？

DDD根据业务抽象出对应业务模型，强项在于业务command消化和处理，query则是其需要辅助的地方。对应的 CQRS(Command Query Responsibility Segregation)读写分离架构理念就是对这一问题的标准答案。

小结：

  1. 资源操作可交由RESTful处理

  2. 业务逻辑承载，非DDD莫属

  3. 查询需辅助，CQRS为你保驾护行

Data Transfer Object - Domain Entity

采用Domain Factory模式封闭领域对象构建复杂度

Domain Entity - Persistent Object

借助Mapper或Converter模式统一行为，方便使用，减少管理复杂度

分层架构

上一页为什么要平台化下一页全流程

最后更新于