实际案例
最近准备将传统项目重构为DDD架构风格，在思考如何将domain层的领域对象持久化到database的时候，遇到了一些问题，核心伪代码示例如下：
/**
* Organization 为领域中的实体，也是一个聚合根
*/
class Organization {
String orgName;
Integer staffNum;
Long orgType; // 外键：组织类型
List<Long> tradeDomains;
Set<Contact> contacts;
}
/**
* 组织类型，数据库生成雪花id主键
*/
enum OrgType {
ENTERPRISE(“企业用户”),
INDIVIDUAL(“个人用户”);
}
/**
* 行业领域，主键id同上
*/
enum TradeDomain {
COMPUTERS_SOFTWARE(1, “计算机软件”, “Computers Software”),
COMPUTERS_HARDWARE(2, “计算机硬件”, “Computers / Hardware”),
…
}
/**
* 联系人，主键id同上
*/
class Contact {
String name;
String phone;
String mail;
}
业务领域问题解释
一个组织聚合中不仅有组织的属性信息，同时也存在行业，有的组织可能跨行业，所以组织同时有多个行业的可能性，用了List去做关联，一个组织可能有多个对外联系人，每个联系人有自己的属性信息。
以上是代码对现实世界的业务对象映射，往往实际应用系统关系比这个还要更复杂。
传统解决思路
1、组织本身的属性在一张表中维护，为了应对未来业务变化，需要增加字段，我们会同时增加一张扩展表（比方名字是organization_ext，未来的业务字段用列值的形式体现，也就是行列互转）；或者使用老套一点的办法预留几个字段，但是并不友好，局限性很大。
2、一对多的关系，上面的实例中一个组织有多个对外联系人（联系人这里我们假设不是用户级别，我们只需要在领域内使用），现实中这种场景很多，比方一个保单，有保单明细，有保单的修改历史等等。用传统的方案，建立一张中间表，用来专门做一对多的关联，当然也可以是多对多的关联。
提出问题
1、如果领域内的聚合关系按照传统方案去做的话，必定会设计多张表，多张表之间需要进行关联关系设定，业务中需要知道及识别这种关系，用MVC的思想去做的话，必然会有很多的DAO接口以及对应的SQL实现，但是DDD的思想，操作单元是一个聚合，这显然是相违背的；
2、DDD思想之下，领域内数据的持久化，许多人提出了存储库模式，也就是对DAO的上层封装及抽象，目的就是为了完全对标聚合单元操作，也即是说承认了数据库的数据格式需要在业务层进行转化的基本事实；
3、用面向未来变化和实时决策的思路去思考，传统的数据存储方案，必然面临数据下沉、分类、抽取、清洗、标签化的过程，以应对OLAP的需要，但是这需要额外的工具支持、开发支持等。
4、现实中，绝大部分场景下，JSON数据有两个特点，可以完美表现业务，也可以完美进行数据分析；结合TiDB的设计思路，按照DDD的业务设计思路，如果能直接对标的话，是不是就可以跨过传统SQL实现（当然不是替代），不需要用schema/table的形式去集约数据，再去做归类分析，以达到OLAP的需要；
5、JSON的特性，默认是支持宽表的，因为面向的就是一个整体，难点在于JSON内容动态变化（比方字段增加、修改、删除），但是这也就是现实世界本身的特点，今天我是A公司的员工，明天我可能是B的员工，再比如：劳动工具以前没有防水功能，但是随着技术的发展完善，如今有了防水功能，等等，现实世界就是变化的，我们是否有办法直接对标DDD的软件设计思想，直接呈现领域知识，并且欢迎他的变化，在变化发生时，从容的应对。
最后
以上问题，希望得到GF回复，欢迎各路大佬一起探讨~
如果有不对的地方，欢迎指正，一起进步~
