08.聚合的上下限 每个黄色点代表一个业务对象，箭头表示它们之间存在的关系，被绿线圈起来的表示这几个业务对象之间存在一致性。到底按哪种方式去将它们聚合是件困难的事情，如果按一致性去划分，很难衡量到底哪几个对象之间一致性更强。再回到DDD的核心方法论：领域驱动模型，模型驱动软件设计。从问题域的角度来看，聚合是紧密联系的一组功能；从软件设计的角度来看，聚合是一个内存单元，包含一组对象，要被。
05-07实现面向对象领域模型-停车案例 在领域模块仅仅是定义，实现在领域外。我觉得这个也可以定义到领域外模块主要是报警策略的定义用到了监听器，所以只能放领域内了。仓储在领域模块内仅仅是定义，实现在领域外模块。
04.DDD与CQRS CQRS全称Command Query Responsibility Segregation，即命令和查询职责分离。它的设计理念来源于单一职责原则。软件系统功能拆解成命令和查询命令：有作用，会导致系统发生变更。查询：无副作用，不会导致系统发生变更。
03.DDD六边形架构 对于程序单元A和B编译依赖：如果要编译A，必须要用到B的编译结果，则在编译期A依赖B。运行依赖：在运行期，如果B不能运行，则A一定也不能运行，则A在运行期依赖B。语义依赖：如果要理解A的语义，必须先理解B的语义，那么A在语义上依赖B。一般A在编译上依赖B，那么A在语义上也会依赖B，因为A使用的B的代码。
MySQL COUNT(*)、COUNT(1)、COUNT(id)、COUNT(字段)效果及性能 效果上，都是统计满足条件的总行数，不考虑是否为null。COUNT(字段)是要考虑是否为空。性能上COUNT(*)>COUNT(1)>COUNT(id)>COUNT(字段)能用COUNT(*)就用COUNT(*)个人感觉，COUNT(1)和COUNT(id)没有存在必要，可以放弃掉，这样简单一点，哈哈哈哈哈哈！
MySQL8.0以下版本重启后自增主键值丢失问题 上周运维同学重启了UAT环境的MySQL数据库服务，刚开始我是不知道数据库重启了，先是业务服务开始异常，初步定位到的原因是一个表的主键ID出现了回退，又查到MySQL低版本（8.0以下）重启可能会导致自增主键值回退或重置，最后和运维同学确认了下重启时间，确认了原因。正如前文中所说，这种方式复杂且风险很大，MySQL8.0并不完全兼容低版本，升级后这个问题解决了，但可能会导致其他方面的问题，所以生产环境一般是不会同意这样做的。在MySQL8.0中，执行同样的操作，自增值仍为6，没有丢失，这里就不演示啦！
Gradel离线、在线编译Java项目 离线编译Java项目，需要jdk、gradle。下载所需版本的gradle和jdk，gradle不区分windows环境和linux环境，但是jdk区分。以下基于windows环境，Linux环境把gradlew.bat换成 gradlew即可。1.进入项目目录2.在当前目录下，打开终端，执行命令。命令中指定gradle路径和jdk路径。本例中使用的JDK版本为windows下的1.8.0_xxx版本，可根据不同环境自行选择。
Clickhouse Code: 173. xxxxx DB::Exception: Couldn‘t allocate 21 bytes when parsing JSON: While xx 我这里是使用Clickhouse对接Kafka消息，建立源表，物化视图并把数据存至目标表。在物化视图中需要对消息进行解析提取关键字段，用到了Clickhouse中的JSONExtractString函数，问题就出在这里。
@SchedulerLock注解使用 name任务唯一标识。最重要的参数。同一个name的任务，同一个时刻，多个线程只会有一个线程获取到锁。其他没有获取到锁的线程会跳过，不会阻塞等待。持有锁的最短时间。这个主要是防止不同节点时间存在误差，比如有个任务是0点执行，节点1的时间是准的，在0点执行花了30秒执行完成。节点2的时间比节点1慢了1分钟，那么节点2到0点的时候，又执行了一次任务。这个参数可以设置10秒、30秒等。保证不同节点的时间戳不会出现。持有锁的最长时间。主要是为了防止死锁。
@Scheduled注解定时任务未按时执行问题记录 经排查原因是因为每分钟执行一次的任务，在1分钟内执行不完，且@Scheduled注解底层虽然是使用线程池，但是线程池中默认只有一个线程！在0点的时候前面还有很多1分钟执行一次的任务没执行完，导致在0点执行的任务阻塞，直到前面阻塞的任务都执行完，1点多才执行0点的任务。在一个项目中多处使用了@Scheduled注解，有些任务是1分钟执行一次，有些任务是每天凌晨0点执行一次。但是发现本该在凌晨0点执行的任务在0点并没有执行，而是在凌晨1点多才执行，而且每次执行的时间还不一样。也可以向下边一样注入配置类即可。
Mongo删除数据 释放空间 最近因为业务需要，需要对Mongo数据库一个collection的一个字段进行调整。该字段本来存储了A,B,C 3个内容，现在需要将A,B,C3个内容分别存到3个字段，并把原字段删掉。这样做了以后，直觉上感觉数据占用磁盘大小应该不会变，因为数据还是那么多数据，只不过分开存储了，原来字段删了。但这样做完以后发现数据占用的空间几乎变大了1倍，已删除的数据磁盘空间没有得到释放。最后，发现mongo占用的内存也很大，我直接重启了mongo服务，发现内存占用变小了很多。显示结果如下：磁盘空间成功释放了5个多G。
Cause: com.mysql.cj.jdbc.exceptions.PacketTooBigException: Packet for query is too large 查阅后发现问题是由于max_allowed_packet参数引起的，该参数是指mysql服务器端和客户端在一次传送数据包的过程当中最大允许的数据包大小。一次插入的数据超过了max_allowed_packet，则会数据库保存失败，报出异常。我这里是批量插入多条数据，数据条数目测有个几千条，数据大小超过了阈值。网上解决方案是修改max_allowed_packet的值，调大这个值，临时修改或者永久修改都可以。比如之前一次插入5000条数据，我这里改成一次插入500条，分10次插入就ok了。
Spring.Shell.History内置命令覆盖 最近工作上遇到的一个小问题，在Spring Shell中，我们可以自己定义一些命令，已完成我们想要的功能，也可以使用内置命令如help、history、clear。但当一些内置命令达不到我们想要的功能时，就需要对其进行重新。如本次遇到的histroy命令，显示的格式是一个List列表，所有命令在一行。而我想要其以每一条命令一行的格式输出，就需要对其进行覆盖。
《微服务架构设计模式》之三：微服务架构中的进程通信 正如刚才所见，你无法使用服务的IP地址静态配置客户端。相反，应用程序必须使用动态发现机制。服务发现的关键组件是服务注册表，它是包含服务实例网络位置信息的一个数据库。服务实例启动和停止时，服务发现机制会更新服务注册表。当客户端调用服务时，服务发现机制会查询服务注册表以获取可用服务实例的列表，并将请求路由到其中一个服务实例。服务及其客户直接与服务注册表交互通过部署基础设施来处理服务发现消息是由消息头部和消息主体组成。消息有几种不同类型的消息。文档：仅包含数据的通用消息。接收者决定如何解释它。
关注
