拿来吧 你 的博客

通过之前的学习，对DDD从设计到开发已经有了一定的了解。DDD作为指导微服务建模的指南，讲了从战略设计 到战术设计的方法。但没有讲解微服务拆分，跟设计的原则。今天就学习下微服务拆分的原则，同时也是领域设计的最有一节。一、微服务设计和拆分要坚持哪些原则？微服务设计原则微服务设计原则中，如高内聚低耦合、复用、单一职责等这些常见的设计原则在此就不赘述 了，主要强调下面这几条： 第一条：要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。 微服务设计首先应建立领域模型，确定逻...

今天开始学习，如何讲前期设计的领域对象转换为代码工程。一.代码模型：如何使用DDD设计微服务代码模型？之前的学习，讲到过一共是有三种架构模式：1.DDD分层架构。2.整洁架构。3.六边形架构。虽然是三种，但是感觉区别并不大，所以今天就围绕DDD分层架构进行代码设计。DDD分层架构首先先回顾下ddd分层架构。代码模型一级目录结构微服务一级目录是按照 DDD 分层架构的分层职责来定义的。从下面这张图中，我们可以看 到，在代码模型里分别为用户接口层、应用层、领域层和基础层，建.

今天开始进入实战篇，实战会讲如何运用事件风暴进行建模，以及代码演示等。一.领域建模：如何用事件风暴构建领域模型？

一.微服务架构模型：几种常见模型的对比和分析上节学习了DDD的分层架构，除了这种，还有整洁架构以及六边形架构。首先看下整洁架构。整洁架构整洁架构又名“洋葱架构”或者clean架构 在整洁架构里，同心圆代表应用软件的不同部分，从里到外依次是领域模型、领域服务、应 用服务和最外围的容易变化的内容，比如用户界面和基础设施。 整洁架构最主要的原则是依赖原则，它定义了各层的依赖关系，越往里依赖越低，代码级别 越高，越是核心能力。外圆代码依赖只能指向内圆，内圆不需要知...

今天主要是学习DDD第七讲分层架构一.DDD分层架构：有效降低层与层之间的依赖 首先看下整体的架构图1.用户接口层 用户接口层负责向用户显示信息和解释用户指令。这里的用户可能是：用户、程序、自动化 测试和批处理脚本等等。 2.应用层 应用层是很薄的一层，理论上不应该有业务规则或逻辑，主要面向用例和流程相关的操作。 但应用层又位于领域层之上，因为领域层包含多个聚合，所以它可以协调多个聚合的服务和 领域对象完成服务编排和组合，协作完成业务操作。 此外，应用层也是

今天主要学了极客时间课程的第五，第六章。下面是今天的记录与思考。一.聚合和聚合根：怎样设计聚合？ 举个例子。社会是由一个个的个体组成的，象征着我们每一个人。随着社会的发展，慢慢出 现了社团、机构、部门等组织，我们开始从个人变成了组织的一员，大家可以协同一致的工 作，朝着一个最大的目标前进，发挥出更大的力量。 领域模型内的实体和值对象就好比个体，而能让实体和值对象协同工作的组织就是聚合，它 用来确保这些领域对象在实现共同的业务逻辑时，能保证数据的一致性。 聚合...

今天重新回到领域驱动设计学习上来，这次主要是通过学习极客时间的课程，感觉讲的还不错，所以接下来要把这个课程通读一遍，并记录下主要内容，供以后翻阅学习。今天主要学习了前五讲，下面记录下今日学习笔记。1.学好DDD，可以做什么？ 在没有DDD之前，划分微服务，大多是都是根据经验，或者业内的一些案例。缺少一个好的指导方法，直到DDD出现后，我们就可以按照DDD的方法论进行业务领域的建模，微服务的分界。所以说 学好了DDD。我们在做业务架构的时候，就可以按照DDD的方法进行业务建模...

领域驱动设计之所以晦涩难懂，个人感觉是名词太多，而且晦涩难懂，今天就整体梳理下 这里面的名词，并结合具体的例子加强理解。一、领域与子域 不管是在软件开发中还是在研究其他问题的时候，我们都可以把复杂问题根据某些特性拆分成多个子问题，每个问题只在特定的范围或区域内研究，这个特定的范围或区域就可以称为领域。 当一个领域的问题还是很复杂的时候，我们可以继续拆分，拆分出来的子领域研究的范围或区域就称为子领域。 例如，以公司为例子，公司拆分了好多业务线，从K0到K5以及其他的...

1.概念CQRS全称：Command Query Responsibility Segregation ，中文名：命令查询与职责分离2.什么是CQRSCQRS 将系统中的操作分为两类，即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称，即我们常说的新增，更新，删除这些操作，都是命令。而查询则和字面意思一样，即不会对数据产生变化的操作，只是按照某些条件查找数据。CQRS 的核心思想是将这两类不同的操作进行分离，然后在两个独立的「服务」中实现。这里的「