领域驱动设计已经广泛被行业接受，当设计一个应用时，大家往往先从领域角度抽象模型，再基于模型之上设计数
据库、服务、界面和流程等。
融都科技基于低代码开发的数字一体化 “担保业务系统”：
个人客户截图
企业客户截图
传统开发方式案例
设计担保系统当事人管理模块时所涉及的领域模型包括：个人客户、企业客户，按照当事人的定义，他们术语当事人领域模型。 在所有行业中，当事人包含的基本信息几乎都差不多，如客户ID、姓名、性别、出生日期、证件类型、证件号码等，但是其他信息多少都会有个性化差异。 即使在同一个行业，例如不同的担保公司，当事人信息也有少许差异，并不完全一致。例如，当事人领域模型除了基本信息，还包含多个账户信息。 当事人管理没有复杂处理的业务逻辑，多数都是增删改查的简单操作。所以面向每一个具体行业，当事人服务接口应该也不会有太大变化。 但是数据模型分类会在不同的类别中，受限于具体领域模型的需求，可能会有较大差异。 只要模型发生了变化，即使保持接口定义原型不变，服务接口具体实施也将发生变化，不同企业的领域模型差异会导致服务无法重用。 以具体需求设计领域模型的方式来设计担保系统当事人管理模块时，软件的产品化程度越低，就越无法适用于多家企业。 其根本原因在于采用了写死的固化模型，缺少抽象，缺乏灵活扩展机制，所以无法重用。 在同一个担保公司的企业内部，当事人除了个人客户还有企业客户，对于企业客户的管理，其服务接口和个人客户管理几乎相同，但是模型变化非常大，个人客户包含的字段信息在企业客户信息中就完全不同了，例如：企业登记号、企业名称、注册时间、注册资本、社会统一信用代码等。 即使企业客户管理都是增删改查这种与个人客户管理相同的功能，但是由于领域模型不同，我们不得不做两套独立的应用或服务来分别管理。 业务需求稍微变化，都会涉及到模型的变化，如果是传统依赖程序员写代码开发，那就引起了程序代码修改、数据库表结构修改，而且这种工作会反反复复，工作量巨大，还都是琐碎重复的、没有任何技术含量的工作，但是开发人员还必须得做这个工作。 |
如何利用戎码Rong Coder（低代码开发平台）来解决上述案例中的问题呢？
戎码Rong Coder（低代码开发平台）允许模型可灵活扩展，以适应不同场景下的个性化需求，可以让应用具有很强的适应性和重用性，且通过可视化配置来定制应用，尽量避免个性化开发工作。
戎码Rong Coder为了解决模型的灵活性，不是在元数据中枚举模型的每一个属性，而是采用对模型本身进行描述，这样表达能力更加泛化的类型来定义模型。
元数据模型包含：结构定义和实例两部分内部。
结构定义部分：用于描述数据结构，即模型。
实例部分：用于描述具体领域模型的对象。
描述数据结构首先要描述每一个属性，确定每一个属性的代码、名称、文字描述和数据类型。
这种定义方式具有很强的灵活性，对于不同业务场景的不同模型，可以在属性中存放不同的属性值，而对应的服务接口保持不变。服务接口实现代码可以动态访问对象中每个属性，并进行逻辑处理。
例如，一个客户下面有多个账户，那么账户数据结构描述的对象中，应该将最大值设置为“>1”，最小值为“0”，这样这个元数据模型就是一个范围。
如何利用戎码Rong Coder（低代码开发平台）通过配置不同的对象来实现对不同领域模型的结构描述，支持领域模型的差异性而不用修改程序代码，能快速响应业务需求。
