很多人说多看多写，其实是需要先学习理论，不然看了也是自己瞎领悟，不知道什么是好代码和好代码的设计原则。
推荐《代码整洁之道》《重构》《架构整洁之道》
设计模式没多少用了，很多都落伍了，完全不需要用

Main 和 Sub 表都追加上同一个范围约束字段，比如 orgId,userId 之类的，代表他们属于某个范围。
所有的索引都以这个范围字段作为左前缀弄联合索引，所有的查询条件都带上这个字段，可以缩小 in 的范围

@wolfie 只有没有 CI ，CR 的团队才会遇到那么多 git 问题。连 protect 这种最基础的都没有，遇到任何问题都不稀罕

LS 几个人别装逼了，生产分支不 protect 能直接 push 显然是技术管理问题，别怪小弟

都是些什么鬼。。。我推荐一个吧
MJUT 去实体店试试，不少衣服设计得不错

@dengkj 我没找到特别好的工具，但是这个东西比较抽象和简单 processon 也能画的，弄几个椭圆画几根线就行。 工程架构也会影响，多子域放到一个工程里 和 每个子领域一个服务的架构上是有区别的，不过对分层影响是不大。我本人使用的是自创的架构，基于菱形对称架构改造而来的

@dengkj processon

@dengkj 技术团队 40 人左右，不过其实和规模无关，和人的能力有关。能力到位了，1 个人也可以用。
规模更多的是决定了工程架构和服务划分的方式，规模小可以把多个 子领域 放到一个工程里面，通过多模块来切分。

@yule111222 补充一下，实体和值对象本身也有行为，也能表达动态性

为什么面向关系数据库的建模方法不够好呢？
有如下原因：
1.二维表难以表达层次结构，出于性能考虑不太可能把一个实体拆分成多张表，这就容易导致复杂的实体表字段非常多认知负担高，且模型难以复用。领域模型通过实体和值对象解决了这个问题
2.二维表也无法表达继承关系，比如 3 个子类继承于同一个父类，它们可以存储在同一个数据库表里面。从表模型上就看不出继承关系了。领域模型是基于 OOP 的，天然可以表达继承关系
3.二维表无法对行为和事件建模，难以表达动态性，领域模型里面可以对领域服务和领域事件建模
4.二维表难以表达关系耦合松紧程度，领域模型通过聚合来约束这个

@reaganlee1947 任何业务逻辑如果需要优雅的实现更好的复用，都需要更复杂的数据结构来支撑。这本身就跟数据库是脱钩的。为什么 Redis 可以实现那么多数据结构，因为是内存数据库。持久化操作仅仅是内存快照(RDB)和指令日志(AOF)的结合。试想一下，如果你的系统运行在一个内存无限大且不需要持久化到数据库里面的环境中，你会如何进行设计？无论用不用 DDD 推荐的工程架构，纯粹的 OOP 方法本身也不需要考虑持久化。在 DDD 的方法里面这部分工作外包给了 Repository 来完成，这个东西本质上是一个适配器，相当于持久化基础设施与核心之间的桥梁。也可以类比 Linux 的 VFS 系统，为什么 Linux 可以支持那么多文件系统而内核维持在很小的体量，也是类似的方法

@reaganlee1947 ORM 框架是个伪 命题，根本不存在。其次，这个只是一个技术基础设施，不论你用什么框架都不会影响领域层的代码。核心业务需要跟技术基础设施完全分离解耦合 再推荐《架构整洁之道》
DDD 属于上层应用方法论里面对综合要求比较多的，需要深入理解设计原则，整洁架构，面向对象，抽象建模等多种能力，才能较好的落地实现。如果没有这方面的专家还是不要轻易尝试的好，容易适得其反

我已经大规模实践过了，非常香，再回去做非 DDD 的工程很难受
推荐《解构领域驱动设计》

youtube 上的 bytebytego 有很多 5 分钟视频介绍一个技术的，你可以拿来讲 15 分钟

太 LOW ，无论是技术还是管理，算了劳动密集型懒得多讲

用时序数据库

java 这个才是正常现象好么一点也不神奇，不如说 Oracle 数据库或者是 windows 自带的计算器中，使用 0.33333333333333333 * 6 ，得到的结果均是 2 才是异常的。盲猜一下不一定准是计算器缓存了前面的除法表达式，然后如果后面有乘法就先做乘法运算，再做除法运算