美目的顾耳，似暮的篝壁

温柔是你的梦，宛如少女的梦

但我扯碎你梦的翅膀

并阐述你的梦

我骑上尤热烈的马

来摩洛哥城堡

似玛瑙潭

柠檬酸了，暖梦熟了

柠檬熟了，暖梦死了

未成熟难梦到愁般

笙变，失败，伤悲

丝般暖梦似乐

溺梦愁编

周三晚上12点从北京发车，为了等车，在地铁附近14块钱一小时的高贵网咖里上了网。刑具中巴车一路的折磨，凌晨三点半到了山东德州。但是人家驾校5点才开门，睡又睡不着，司机师傅睡得倒是挺香，呼噜震天响。没办法，只能干等着。

终于等到驾校开门，教练开着小车来上班了。场地属实是破败不堪，杂草丛生。上午就开始练车，教练吊儿郎当的给我们讲技巧，我们听着记点位。驾校的小三轮年久失修了，一上午就有两辆车没法用了，好在我们人不多，还有备用的车。和我组队的一个哥们他是科二科三都挂了，过来补考来了。我心思这不是包过的吗？咋还有补考的？我不会也会挂了吧？

一上午的时间很紧凑，我甚至科三都没练上，教练就要求集合，开始两边模拟考试。第一次模拟的时候，我再绕桩的时候神志不清了，左右不分的从错误的地方进场了，被教练狠狠滴侮辱。然后还疯狂的装杆。我以为我已经够笨的了，没想到还有五星级米其林厨师在后面，不仅进反了，比我还要拉跨，那操作不是人能开得出来的。我是两遍都差点儿意思，感觉考试有点儿悬。

练到中午十二点多，驾校开始带着我们去考科一，科一当然稳稳的。考完了之后，我和我的小伙伴找了一个空调房呆着，过了一会儿，外面没动静了。我们出去一看，人都没了。在群里一问，才知道他们都坐车去科二的考场了。还好那边不算太远，大概两公里左右。没办法，只能腿过去了。真的是又累又饿，天气还闷热。一路走过来，我和我朋友都精神萎靡了。顺着导航走到了一片苞米地，旁边有一个上了锁的大铁门，门里的自建房有个牌子写着科二科三考场。这是一个相当隐蔽的场地，教练已经给学员看完了场地了，给我俩简单的侮辱之后，给我俩报了名，也没重新给我俩讲。

看了场地之后，怪不得能包过呢。这小考场透露着寒酸。院内的绿化相当可以，屋内候场的监控屏幕上写着java.lang.NullPointerException还自带3秒一次的闪烁，水泥地面上的黄线有些斑驳。感觉我家的院子里收拾收拾都能开个考场了。绕桩场地的容错比驾校的要高一些，也可能车上的设备没有那么灵敏，只要别错的太过分，应该是能过的。有两个大爷确实没过去。（是做共享单车投放的）。考的时候有点儿紧张，感觉差点儿就蹭到杆子了。

考完科四之后，终于到了领证环节！教练给大家发了证，时间已经来到了下午4点。我们是不想再体验中巴车，买了高铁的票。这是我做过最快的高铁了。眼睛一闭一睁，到北京了。仔细算了一下，从周三早上七点起床，到周四的下午五点，真的是没好好休息过，也没正经吃过饭。还好最终的目的达到了。要是真挂了，死的心都有了。

现在可以研究买摩托了。第一辆摩托买哪个好呢？大家有没有推荐的？身高187体重200的我骑什么车好？豪爵TR300行么，是不是骑上去真的老了10岁？

最近看了伊藤润二的漫画，密集的线条从视觉上就带来的压抑感和恐惧感。

最开始接触伊藤润二的漫画还是在初中的时候，这种画风就激起了我强烈的猎奇心理，自己也被它吸引，卷入旋涡之中。

故事跟随女主的视角，见证了漩涡镇在旋涡的诅咒中慢慢崩坏、扭曲，最终旋涡的诅咒也不会结束，还会在历史的轮回中重现的故事。

故事的每个章节都可以算作一个独立的故事，从最开始男主的爸爸痴迷旋涡图案，最终以肉身化作旋涡。每个沾染旋涡诅咒的人都会因为自己心中的欲望不断扭曲。不知道是因为内心的扭曲产生了诅咒，还是因为诅咒影响了内心，人们越来越极端，对身边发生的异常现象也视而不见。因为恐惧旋涡，不断怀疑自己，被旋涡吸入。因为自恋情绪膨胀，最后自己也被旋涡吞噬（连舔狗也被吸入惹）。因为渴望被关注，头发被旋涡寄生，最后被吸干。整个镇子慢慢被旋涡诅咒，卷入旋涡的中央，无法逃离，走向崩坏。人性的自私，残忍展现出来，从想要逃离诅咒，到放弃挣扎，最后享受诅咒的快感，人吃人好像是一种享受。而男女主却能在旋涡中保持自我，但最后也无法逃离旋涡的诅咒，在发现旋涡镇诅咒的真相后一起走向了结局。

人的欲望是无穷的，一旦放纵起来，就会陷入疯狂，在欲望的旋涡中无法逃离，连自己都无法意识到。所以还是要对自己有一个清晰的认识才行。

旋涡周而复始，一切似乎已经结束，也许只是开始。

感觉最近除了上班就是上班，啥都没干，啥也不想干。

每天下班就想躺着，和朋友开黑，打打游戏，看看漫画，刷刷b站。

是不是躺平了？ 不！是懒癌发作了！

要是以前的我肯定觉得现在自己太堕落了，天天不思上进。

但是现在我觉得这样挺好的，这样才叫享受生活。（可能是我太不会享受了）

猫变圆了，但是我没有，有也不承认。

三月，逛了南锣鼓巷，巷子很黑。吃了烤肉，吃撑了！

四月，家乡的撒库拉开了，去逛了公园，还划了小艇，很开心!

五月，搬家了，新家说话都带回音，得劲！

还顺便过了非30岁的生日，之后干了个爽。

2023.05.20  树🌲和云☁️都好潦草😅

2022.05.21 蓝天白云终于像那么回事儿了 🥹

第一次上手搞这些东西令我犹犹豫豫，不敢下手。

领域模型和数据模型

领域模型一般是贴合业务的，数据模型一般是注重技术实现上的。

领域模型关注的是领域知识，是业务领域的核心实体，体现了问题域里面的关键概念，以及概念之间的联系。领域模型建模的关键是看模型能否显性化、清晰的表达业务语义，扩展性是其次。
数据模型关注的是数据存储，所有的业务都离不开数据，都离不开对数据的 CRUD，数据模型建模的决策因素主要是扩展性、性能等非功能属性，无需过分考虑业务语义的表征能力。

通常我们的定义的实体中，一般不会带有行为，只是属性，一堆get/set，没有增删改查等操作，这些操作一般在service中。
领域模型中的实体是会有的，把领域对象看成一个实体，这个实体在各种状态变换后仍是保持一致的，而不是属性的变换。对这些对象而言，重要的不是其属性，而是其延续性和标识。

实体和值对象

定义：
实体：许多对象不是由它们的属性来定义，而是通过一系列的连续性（continuity）和标识（identity）来从根本上定义的。只要一个对象在生命周期中能够保持连续性，并且独立于它的属性（即使这些属性对系统用户非常重要），那它就是一个实体。
值对象：当你只关心某个对象的属性时，该对象便可作为一个值对象。为其添加有意义的属性，并赋予它相应的行为。我们需要将值对象看成不变对象，不要给它任何身份标识，还应该尽量避免像实体对象一样的复杂性。

当然如何划分实体与值对象是根据业务来的。

实体人员，原包括：姓名、年龄、性别及所在省、市、县和街道等属性。这样显示地址相关属性就很零碎。
就可将 “省、市、县和街道等属性” 拿出来构成一个 “地址属性集合”，该集合就是值对象。领域模型会更加贴合面对对象编程，对象之间有明确的上下文关系。
在领域模型中人员是实体，地址是值对象，地址值对象被人员实体引用。在数据模型设计时，地址值对象可以作为一个属性集整体嵌入人员实体中，组合形成上图这样的数据模型。

贫血模型

在贫血模型中领域模型一般都是贫血模型。平常用的mvc架构基本上都是如此。

举个例子来讲，User、UserDAO 作为数据访问层，UserBO、UserService 作为业务逻辑层，UserVO、UserController 作为接口层；

其中 UserBO 只作为纯粹的数据结构，没有业务处理，业务逻辑集中在 Service 中。

像 UserBO 这样的纯数据结构的就可以称之为贫血模型，同样的还有 User 和 UserVO，这样的设计破坏了 Java 面向对象设计的封装特性，属于面向过程的编程风格。

充血模型

基于充血模型的 DDD 开发模式，与贫血模型相反的是，充血模型将数据和业务放在一个类里面。DDD 领域驱动设计，DDD 核心是为了根据业务对系统的服务进行拆分。领域驱动设计的核心还是基于对业务的理解，不能一味追求这样的概念。

对于充血模型的开发的 MVC 架构，其核心区别在于 Service 层：包含 Domain 类和 Service 类。Domain 对于 BO 而言，添加了一定的业务逻辑，降低 Service 中的业务逻辑量。那么充血模型对于贫血模型好在哪里呢？

对于贫血模型而言，由于数据和业务的分离，数据在脱离业务的情况下可以被任务程序修改，数据操作将不受限制等。

为什么贫血模型这么盛行？一是对于大部分业务而言都比较简单，基本上都是围绕 SQL 的 CRUD 操作，仅仅通过贫血模型设计就可以完成业务。而是充血模型的设计难度较大。

DDD分层架构

领域模型关注的是领域知识，是业务领域的核心实体，体现了问题域里面的关键概念，以及概念之间的联系。领域模型建模的关键是看模型能否显性化、清晰的表达业务语义，扩展性是其次。

数据模型关注的是数据存储，所有的业务都离不开数据，都离不开对数据的 CRUD，数据模型建模的决策因素主要是扩展性、性能等非功能属性，无需过分考虑业务语义的表征能力。

1.用户接口层 UI，负责界面展示。
2.应用层Application Layer，负责业务流程
3.领域层Domain，负责领域逻辑。
4.基建层Infrastructure Layer，负责提供基建。
分类的依据是：越往上，预期变动越频繁；越往下，预期变动越少。

用户接口层

面向前端用户提供服务和数据适配。这一层聚集了对外接口和数据适配相关的功能。用户接口层在前后端分离设计时，主要完成后端微服务与前端不同用户的接口和数据适配。

用户接口层主要有Facade接口和DTO以及DO数据的组装和转换等代码逻辑。

应用层

应用层是用来连接用户接口和领域层的，很薄的一层，主要只能是协调领域层多个聚合完成服务的组合和编排，调度用的，不体现业务逻辑。

应用层之上是用户接口层，在应用层完成领域层服务组合和编排后，应用服务被用户接口层Facade服务封装，完成接口和数据适配后，以粗粒度的服务通过API网关面向前端应用发布。

此外，应用层也是微服务之间服务调用的通道，微服务在应用层可以调用其他微服务的应用服务，完成微服务之间的服务组合和编排。

在应用层主要有应用服务、事件订阅和发布等相关代码逻辑。

其中，应用服务主要负责服务的组合、编排和转发，处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。

注意：在微服务设计和开发时，应用层主要职能是服务的组合和编排，切记不要将本该在领域层的核心领域逻辑在应用层实现。这会使得领域模型失焦，时间一长应用层和领域层的边界就会变得混乱，边界清晰的四层架构慢慢可能就演变成了业务逻辑混杂的三层架构了。

领域层

领域层位于应用层之下，是领域模型的核心，主要实现领域模型的核心业务逻辑，体现领域模型的业务能力。用来表达业务概念、业务状态和业务规则，可以通过各种业务规则校验手段保证业务的正确性。

在设计时，领域层主要关注实现领域对象或者聚合自身的原子业务逻辑，不太关注外部用户操作或者流程等方面的业务逻辑。所以在领域层主要体现的是领域模型的能力。外部易变的如流程、业务组合和编排的需求由应用层完成。这样设计可以保证领域模型不易受外部需求的变化而受影响，从而保证领域模型的稳定。

领域建模时提取的大部分领域对象都放在领域层。微服务的领域层可能会有多个聚合，聚合内部一般都有聚合根、实体、值对象和领域服务等领域对象。它们组合在一起协同实现领域模型的核心业务能力。

注意：在选择用实体方法或者领域服务实现业务逻辑时，请记住不要滥用领域服务。如果将单一实体自身的业务行为也用领域服务来实现，这样就很容易变成贫血模型。

基础层

基础层贯穿了DDD所有层，它的主要职能就是为其他各层提供通用的技术和基础服务，包括如第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。我们常见的功能是完成实体的数据库持久化。

基础层主要有仓储服务代码逻辑。仓储采用依赖倒置设计，封装基础资源逻辑的服务实现，实现应用层、领域层与基础层的解耦，降低外部资源变化对领域逻辑的影响。

微服务代码目录结构

服务视图

基础层

基础层的服务形态主要是仓储服务。仓储服务包括仓储接口和仓储实现两部分。
仓储接口服务可以供应用层或者领域层服务或方法调用。
仓储实现服务完成领域对象的持久化或提供数据初始化所需要的PO数据。

领域层

领域层实现核心业务逻辑，负责表达领域模型业务概念、业务状态和业务规则。
领域层主要服务的形态有实体方法和领域服务。
实体采用充血模型，在实体类内部实现实体相关的所有业务逻辑，具体实现形式是实体类中的方法。实体是微服务内的原子业务对象，在设计时我们主要考虑实体自身的属性和业务行为，实现领域模型的核心基础能力，这是一种面向对象的编程方法。
实体方法不过多考虑外部操作和业务流程，这样才能保证领域模型的稳定性。
DDD提倡富领域模型，尽量将业务逻辑归属到实体对象上，实在无法归属的部分则设计成领域服务。领域服务会对多个实体或实体方法进行组装和编排，实现跨多个实体的复杂核心业务逻辑。
你也可以认为领域服务是介于实体和应用服务之间的薄薄的一层。它的主要职能是实现领域层复杂核心领域逻辑的组合和封装。
采用严格分层架构时，实体方法如果需要对应用层暴露，则需要通过领域服务封装后才能暴露给应用服务。

应用层

应用层主要面向前端应用和用户，根据前端用例和流程要求，通过服务组合和编排实现粗粒度的业务行为。
应用层主要服务形态有：应用服务和事件订阅服务。
应用服务负责服务的组合、编排和转发，负责处理业务用例的执行顺序和结果的拼装，负责不同聚合之间的服务和数据协调，负责微服务之间的事件发布和订阅。
通过应用服务对外暴露微服务的内部核心领域功能，这样可以隐藏领域层核心业务逻辑的复杂性和内部的实现机制。
应用服务用于组合和编排的服务，主要来源于领域服务，也可以是外部微服务的应用服务。
除了完成服务的组合和编排外，应用服务内还可以完成安全认证、权限校验、初步的数据校验和分布式事务控制等功能。
提示：为了微服务内聚合的解耦，聚合之间的服务调用和数据交互，可通过应用服务完成。原则上我们应该尽量避免聚合之间的领域服务直接调用和聚合之间的数据库表关联。

用户接口层

用户接口层是前端应用和微服务之间服务访问和数据交换的桥梁。
用户接口层的主要服务形态是facade接口服务。
facade接口服务处理前端发送的Restful请求和解析用户输入的配置文件等，将数据传递给应用层。或者获取应用服务的数据后，进行数据组装，向前端提供数据服务。
facade接口服务分为接口和实现两个部分，完成服务定向。通过assembler组装器，完成DO与DTO数据的转换和组装，完成前端应用与应用层数据的转换和交换。
facade接口服务本质上就是端口适配器架构模型中的适配器，面向前端应用和用户提供主动适配。

数据视图

在DDD中有很多的实体和数据对象，这些对象分布在不同的层里。它们在不同的阶段有不同的形态，分别承担不同的职能。
数据持久化对象 (Persistent Object，PO)，与数据库结构一一映射，它是数据持久化过程中的数据载体。
领域对象（Domain Object，DO），微服务运行时核心业务对象的载体，DO一般包括实体或值对象。
数据传输对象（Data Transfer Object，DTO），用于前端应用与微服务应用层或者微服务之间的数据组装和传输。是应用之间数据传输的载体。
视图对象（View Object，VO），用于封装展示层指定页面或组件的数据。
可以通过下图来具体了解微服务各层数据对象的职责和转换过程。

基础层

微服务基础层的主要数据对象是PO。在设计时，我们需要先建立DO和PO的映射关系。大多数情况下DO和PO是一一对应的。但也有DO和PO多对多的情况。在DO和PO数据转换时，需要进行数据重组。对于DO对象较多复杂的数据转换操作，你可以在聚合用工厂模式来实现。
当DO数据需要持久化时，先将DO转换为PO对象，由仓储实现服务完成数据库持久化操作。
当DO需要构建和数据初始化时，仓储实现服务先从数据库获取PO对象，将PO转换为DO后，完成DO数据构建和初始化。

领域层

领域层主要是DO对象。DO是实体和值对象的数据和业务行为载体，承载着基础的核心业务逻辑，多个依赖紧密的DO对象构成聚合。领域层DO对象在持久化时需要转换为PO对象。

应用层

应用层主要对象有DO对象，但也可能会有DTO对象。应用层在进行不同聚合的领域服务编排时，一般建议采用聚合根ID的引用方式，应尽量避免不同聚合之间的DO对象直接引用，避免聚合之间产生依赖。
在涉及跨微服务的应用服务调用时，在调用其他微服务的应用服务前，DO会被转换为DTO，完成跨微服务的DTO数据组装，因此会有DTO对象。
在前端调用后端应用服务时，用户接口层先完成DTO到DO的转换，然后DO作为应用服务的参数，传导到领域层完成业务逻辑处理。

用户接口层

用户接口层主要完成DO和DTO的互转，完成微服务与前端应用数据交互和转换。
facade接口服务在完成后端应用服务封装后，会对多个DO对象进行组装，转换为DTO对象，向前端应用完成数据转换和传输。
facade接口服务在接收到前端应用传入的DTO后，完成DTO向多个DO对象的转换，调用后端应用服务完成业务逻辑处理。

前端应用

前端应用主要是VO对象。展现层使用VO进行界面展示，通过用户接口层与应用层采用DTO对象进行数据交互。
提醒：数据转换主要目的是为了各层解耦，以保证领域模型的稳定，也是为了让微服务具有更强的扩展能力和适配能力。但每一次数据转换都是以性能作为代价，在设计时需要在性能和扩展能力之间找到平衡。

在海边散步的三个野人：

在下了第一个野人洞之后，我觉得自己行了，用龟壳滑下大坑，不料没整好，摔死了。
为了拿回自己的尸体，接连死了四次，啥都没了，因为死的太快，连送的手斧都没了，陷入了死亡循环。我受不了了，我崩溃了。
在重新读档之后，游戏进度又回到了第一天玩的时候，这次不狂了，还是在海边建基地吧。

砍原木真是效率太低了，还得来回搬运。想上网查一下有没有加快效率的方法，发现了有小推车，又无意中发现可以利用bug刷资源，这下一发不可收拾，开始罪恶的卡bug。

此时在bug的帮助下，基地已经比较壮观了：

我直接化身为森林设计师，少一块平台的死亡楼梯，将老寒腿的扬哥摔死。恐怖围墙，将扬哥围困的动弹不得。
高速致命滑索会直接飞到海里，游上来直接获得debuff又湿又冷。
我感觉这游戏坑队友才是最快乐的。

变异野人拆家太快，大胖子一屁股就会给围墙干碎，队友打野人，我在后面苟着修围墙哈哈哈！
为了防御野人，在家门口设置陷阱，最主要的作用还是用来。。。坑队友。哈哈哈！
正门口全是陷阱，一不小心老寒腿发作，就要被打掉血。
大家出门都小心翼翼。

探索了全岛，该拿的武器道具也都拿到了。
满装备重新进发大坑：

要我说信号枪才是这个游戏的神器。趁队友不在电脑前，一发信号弹点燃队友，然后赶紧跑，装作无事发生。在角落里听队友的惨叫，宛如天籁一般！太美妙了！

深情对视的二人：

提米和他的三个老父亲：

最后也是选择了放弃拯救儿子，拯救了全世界。

用鞭炮后入：

最后再看一眼基地

我的评价是：不想再玩第二遍。
并不是说这个游戏特别难，而是玩起来确实不开心,玩的时候心里窝着火。

操作手感：作为动作游戏来讲，手感挺不错，有点儿惯性，但不是脚底抹油那种。需要小小适应一下。
游戏节奏：循序渐进，每关都会获得一个新能力。能力多了游戏内容更复杂，更难。
美术：像素，感觉颜色很扎眼。整体就是蓝绿红黑这几种颜色。主要满屏鲜红的刺儿，嗯，刺太多了！最后一关整个屏幕几乎都是红色，角色在跑动时，配合这个颜色令我的眼睛十分甚至九分的疲劳！狗看了摇头，我看了流泪。
音乐：忘记了，没留下什么印象。
核心玩法：平台跳跃类游戏，主打一个跳跃、避障、追逐、地形杀、时机。高惩罚性。

简评：
整体流程较短，是一款为了难而难的游戏。除了需要耐心，技术以外，还需要人品。
游戏后期刷怪的机制让人难受。小怪物会在地图上逛，还会随机加速，运气不好就会回家。
有时需要耐心等待机关。浮游炮攻击频率不固定，要耐心等怪物被打死再移动。
有的地方需要盲视野跳跃，试错成本比较高。
有时感觉是因为流程短做的故意拖延，堆怪。感觉只留下关键怪物刷新就好，不必一直刷新小怪。
后续可以多出一些关卡，地形杀是不错的，需要背板的地方多来点儿。因为我个人不太喜欢这种太拼运气的地方。随机要素让我比较心烦。
最终boss打起来也是看运气，boss房里会刷小怪。如果不刷追踪小怪的话，游戏会简单很多。

今天打算再种一点儿猫草，拿出来种子一看，里面已经生米虫了。
明明上周还没有来着，吃的种子上全是小洞。

这米虫叫“米象”，看起来是象鼻虫的一种吧。

想起来我在小时候还养过一些虫子，当时觉得好玩，抓起来放在一个磁带盒里，
每天投喂一点儿菜叶子。
不知道养了多久，最后都全军覆没了。
记得这里面有金龟子、象鼻虫、蜗牛、还有些不知道叫啥的虫子。
都是长得挺奇特的。

金龟子颜值是可以的，背甲很漂亮！捉了好几只关在里头。

前方米虫出没！