zh2526

1.DDD带来的问题 为了遵守"代码和模型一致的原因"，引入的问题： 1）程序编写比较麻烦，原来一句 SQL 就可以解决的问题，现在要分几步实现。 2）这样的程序可能带来性能问题。 核心问题是，查询功

1微服务的设计方法 1.1微服务设计要考虑的几种情况： 第一，不同的可伸缩性要求 需要动态伸缩的，单独划分出来，以便低成本增加容器。 第二，不同的安全性要求 有的功能要接入互联网，有的要放在内网，需要

基于划分出的限界上下文，可以设计系统的架构。使用微服务还是单体架构需要综合考虑，通常要根据投入产出、人员能力、基础设施等因素做出权衡。 一般在满足如下条件时，才建议使用微服务，否则还是用单体架构。 第

1背景 随着系统规模演进，经常出现如下问题： 1.1沟通成本变大 1.2代码质量变差 1.3回归问题 1.4单体架构导致的需求更新等待 1.5不支持横向扩展 2.解决方案-拆分系统 拆分的方法是什么呢

1.概念图 1.1聚合 聚合（aggregate）是一组有整体部分关系，并且要满足一定不变规则的领域对象，其中只有一个实体表示整体，这个实体叫做聚合根。 1.2不变规则 指的是每时每刻都不能打破的规则

泛化的代码实现 主要两个点： 一是领域对象的代码采用类的继承或接口的实现； 到底用类继承还是接口实现，则要根据具体情况而定。今天工时项的例子用的就是接口实现，而客户的例子用的则是类的实现。而如果我们在

三种数据库设计策略的优缺点 1.1每个类一个表 不管父类还是子类，都各建一个表;如下图： 1.2每个子类一个表 只为子类建表，父类不单独建表，而是把公共属性分别放在子类。 1.3整个泛化体系一个表 此

1.在模型中识别泛化的过程可以有两种，一种是归纳法，也就是先识别出了一些类，然后发现它们之间有共性，于是抽象出父类。另一种是演绎法，也就是先识别出了一个类，然后发现这个类又可以分成几种不同的情况，于是

为了实现“为内部项目报工时”引发的需求，比较了使用泛化和不使用泛化两种方式。最后选择了从业务和技术视角都更加简单的，不使用泛化的方式。这说明，使用或者不使用泛化，是一个需要权衡的决策。在权衡过程中，需