王树贤

大神，好几张图都不显示。

已缓存的公共仓库的包如何更新呢？

>when use a json file with image,i found that animation.isLoaded was false,  >but when use a json file without image,i found that animation.isLoaded was true,  ```ts setImmediate(() =>...

请问作者的 ER 图是如何制作的？

Proxy部分很强大很简洁～～～～谢谢

# MVC vs DDD ## MVC等传统开发方式：以数据为起点去开发整个系统 >先动手建立表结构，再针对表数据进行 CRUD 组装出功能点。 >业务逻辑极其混乱，为了完成一个功能点，代码就是往上堆 >数据库表又是一个很敏感的东西，不会动不动就大改表结构。那为了能够满足日益复杂的需求，你只能够加表、加字段、加 if/else 的逻辑嵌套。 ### MVC，全称 Model View Control（模型-视图-控制器），其分层定义如下。 >M（模型层/ DAO 层） ：业务数据载体层。 >V（视图层/ Controller 层） ：展现给用户的数据表示层。 >C（控制层/ Service 层） ：接受...

# DDD 设计 >DDD 不是 MVC 那种业务通用性的分层架构（任何业务都能按照固定的技术形态进行套用）。 >它不是一个固定的技术工具形态，针对不同的业务它有不同的呈现方式。 >DDD 的核心战略目标是解耦与内聚，为了完成这个战略目标，它定义了领域、子域、限界上下文、通用语言、上下文映射图和架构风格的概念。 ## 领域与子域 ### 领域 >领域是 DDD 架构落地设计的核心。 >一种专门活动或事业的范围、部类或部门。 >在 DDD 中，领域本身并不是一个学术性很强的概念，任何边界明确的业务都能被称为领域。 >比如，一个电商平台中，订单、物流、支付等都是这个平台的领域。 ### 子域 >针对一个领域做二次划分它就是子域了。 >领域和子域都是相对的概念。 >如果把电商平台看成一个大的电商领域，那么订单、物流这些就是它的子域。 >但如果把订单看成一个领域，那么商品、订单明细等就是它的子域。 ### 电商系统...

# DDD 的战略设计 >DDD 的战略设计包含了：领域、子域、限界上下文、通用语言、上下文映射图和架构风格。 >战术设计为了匹配战略设计主要包括以下概念：聚合、聚合根、实体、值对象、应用服务、领域服务、仓储、事件模型等。 ## 聚合、聚合根、实体与值对象 >领域/子域是 DDD 战略设计中最核心的业务体现。 >那么对应到代码层面，领域/子域的概念的呈现方式是什么呢？答案是：聚合。 >为了描述聚合内部的属性，DDD 定义了实体与值对象的概念。 >最后，领域的逻辑呈现要在一个限界上下文中才有意义，必然要有一个概念来包括下领域的逻辑与定义业务的边界，这个就是聚合根。 ### 实体 >实体 = 唯一标识 + 生命周期（可以理解为属性可变） >实体是描述某一可连续变化的物体。它是具有生命周期的，并且可以通过唯一标识来确定是否为同一个实体。 >比如，现在有两个长相一模一样的双胞胎分别叫张三与张四。他们是独立的个体，大家不会因为他们长得一样而认为他们是同一个人。他们刚出生的时候什么都不会，随着年纪的增长，张三成为了科学家，张四成为了企业家。但是他们并不会因为各自的身份属性变更，而导致他们不是张三与张四了，因为本质上他们这个人的唯一标识在成长过程中一直未改变。 ### 值对象 >值对象 = 不变性 +...

# DDD 事件风暴 >DDD 如何消除需求分析与同步过程中的信息不对称 >从工程角度来看，DDD 很多专有名词与结构划分都是基于解耦模式下的套路。 >从落地 DDD 的过程来看，有两个问题是最困难且最重要的：一个是界定出一个系统中有多少个聚合，即划分多少个业务模型；另一个是界定出每个聚合之间的限界上下文，即划分清楚领域的业务边界。 >为了解决以上两个痛点问题，一种被叫作事件风暴的轻量型系统分析方法被提出。 ## 事件风暴的概念及流程 >事件风暴是一套 Workshop（类似于头脑风暴）的方法。 >它以事件为出发点，通过多人协作来划分业务领域与业务边界。 >事件风暴的分析过程就像在讲述一个个的用户故事。 >通过一个个的用户故事来统一开发人员、业务人员、UX、测试等项目参与者对业务流程的认知，这包括关键的流程、核心的业务规则、系统不同模块的使用。 >其次是帮助开发人员梳理清楚领域模型与业务边界。 ### 用户故事的分析 >事件风暴对于用户故事的分析的最简核心流程：  >事件风暴的核心流程就是：用户执行了命令，从而产生了事件。 #### 事件： >代表了某一个业务行为，是事件风暴中的核心概念，所有的分析都以事件为核心展开。 >描述的形式为“宾语+动词”的过去式。 >例如，合同已被签署、资料已被上传，等等。 >使用橙色的便利贴标示。...

# DDD 项目架构 >通过三层架构对比演进的方式介绍常用的两种 DDD 架构。 ## 六边形架构演进之路 ### MVC 的分层架构  >从上往下依次对应了用户接口层、业务逻辑层与数据服务层。 >它的显著优势就是：结构足够简单，不管业务简单还是业务复杂的系统都能往上套。 >因为本质上它的分层思想是工程化分包思想，而不是业务化分包思想。 ### 六边形架构 >为了将纯工程化思想转化为业务驱动架构思想，DDD 提出了六边形架构来解决日益庞大的系统维护困难的问题。 >DDD 的架构分层模型不止六边形架构这一种。 >DDD 的架构在市面上被说到比较多的就是四层架构、五层架构与六边形架构。 >为什么最终我们在使用 DDD 的时候，基本上都是选择六边形架构而不是四层架构或者五层架构呢？ >下面以四层架构为例给大家阐述其中的演变过程。 #### MVC 直接映射...