ToyBrick框架使用有感
2024 / 09 / 06
这是脱离上个团队后第一次全面地使用ToyBrick框架后的感受，当前业务场景不复杂分为一个专注数据操作的数据中心和一个同步操作的集群程序，目前架构为数据中心通过参数往不同的集群的数据库读写数据，数据中心本身维护一套全局表用于定位路由和集群。这篇随想主要分析对在这个场景下使用ToyBrick所带来好与坏。
首先ToyBrick在设计之初是希望把DDD领域建模的思想落实下来，整个框架的核心在于aggregate中的能力接口，在我原本的理解中，一个实体具有完整的值和能力，在我需要把这个实体和其他实体组合起来进行操作时会创建一个聚合对象，把这两个实体放在这个聚合对象中作为参数，这个时候我遇到的问题是我只是需要一个实体的某个能力，这个能力传入的是一个DTO对象而不需要原本实体的值对象，这种情况经常出现，如果我在接收到dto的同时把数据转成值对象，这一步会有点过度设计，目前我的操作是，一个不需要对外部提供对外服务的实体只需要提供能力的接口，这样在形成聚合对象的时候只把能力作为属性而不是整个实体，目前这种做法是否正确还有待商榷…
在依赖注入这一块，当数据库中的表越来越多甚至只超过十张表时，通过uber.Fx来进行维护过于繁琐，同时为了防止每个请求进来走同一个实体，使用了工厂模式，在多种因素作用下整个代码变得过于笨重，对项目花费的时间不再是在领域构建上，而是在添加各种依赖上，之前写过一个代码生成的工具太客制化，后续这个问题可以通过修改工具解决。
在面对快速变化的需求时DDD确实起到了很大帮助，每个实体都想工具包一样互相组合完成任务，这点好处毋庸置疑，现阶段我面临的问题是在面对小项目但存在一点复杂程度，并且面对随时变化剧烈的项目时，我该怎么选择使用MVC还是DDD，这套代码因为有要求的全局变量存在，但这个全局变量耦合的过于紧反而起不到全局的作用容易引起循环依赖，这是过去代码存在的问题，而不是ToyBrick自带的，在剥离这个假全局变量时遇到的阻力可以说是整个项目中最大且最麻烦的，警惕垃圾设计和不考虑包结构的变量。
总的来说ToyBrick给我的帮助很大，更清晰的逻辑结构，更快的排查速度但存在的对实体结构的不易修改依旧是很大的问题。
常练常新，静待日后…
2024 / 10 / 08
ToyBrick框架由昂哥牵头搭建的，说实话我在其中的角色实在是个学习者加应声虫，虽确实学到了很多东西但终究没有从根源理解，再加上新工作实在轻松，故我该抽取两天出来加班学习这方面的知识….实在该开始克制自律
2024 / 10 / 17
新项目在多次新需求和修改需求的情况下存在了腐化的现象逐渐出现以下问题
领域之间存在互相调用的情况，这一点非常不应该，应当接受对领域的独立性做的代码冗余
在不同层进行参数传递时应对参数进行转换和收敛，保证接口参数的使用率，减少调试的压力
当前项目简单并没有特别复杂的业务，故不该在一开始有热血上头积极实践DDD应当按照实际情况进行结构选择。
另：原Toybrick中实体，值对象组成聚合，对于实体的属性和值对象的属性一直存在较多争议应加强理解，对于Toybrick中依赖注入的方式，是否存在更好的解决办法，目前依旧在寻找解决方案，原项目在连接过多时会出现注入过多的Client，事实上这些Client只是根据数据连接的实例化而已。
寻找练习方向，想清楚走哪条路线。
2024 / 11 / 21
在阅读《领域驱动设计》一书后对Toybrick框架有了更深的理解和不同的想法
- DDD设计实在不该被困在某个具体的框架当中，它的扩展性和延生范围可能会非常广，Toybrick固定了实体中能力接口+ID+值对象的配置，当一个实体的能力它不需要抽象只要具体实现时，Toybrick就会陷入过度设计的泥沼。
- 原有的业务过于简单导致遇到问题依旧浅显只需要单聚合就可以解决，而且只涉及到一张表这就导致，原有的设计依旧是被数据库牵着鼻子走，并没有实现数据库考虑存储而领域考虑业务的问题。
- 使用fx做依赖注入还是过于繁琐，并且原有业务对象不够抽象给人的感觉依旧非常MVC。
- 当时接手的是重构项目，贸然使用DDD过于冒进和鲁莽。
- 一个model对应一个client还是过于僵硬，单表操作方便但是涉及过多时会产生SQL语句不知放在哪里的操作。
- Toybrick中的外部能力或者说基础设施层的东西可以抽象。
- 适当的贫血模型更符合开发效率。
- 在动手开发前没有先划分好领域范围，也没有先设计类图而是写完之后再生成，这个错误非常严重，先开枪再立把子会导致开发人员权力过大，当开发人员影响模型而不做约束的话，那结果会离模型越来越远，最后模型彻底无用。
DDD领域驱动设计需要长期小步迭代来逐渐发现模型中的问题，这就不适合前期工期紧张，业务不复杂，需求变动不频繁的业务场景。
小步重构引起深层模型的浮现，迭代到深层模型必然是大规模的重构。
