如果技术架构实现了用业务语义而不是技术语义来表现技术内涵,那么这个架构无疑就是成功的。这里的业务语义是什么意思呢?主要是指业务层次的元数据描述(包括对象层次和各种不同业务场景下的校验逻辑、显示逻辑、可编辑性逻辑、触发器)。
对于普通业务开发人员而言,无需了解底层的架构,不需要了解外键是什么、主键是什么、系统线程如何调度、数据库表有哪些列、表和表之间如何进行关联等技术语言,而只需要了解并向系统表述清楚是什么样(对象A是否包含,包含几个对象B或反之)的关联(外键)、使用哪几个字段来唯一确定一个业务对象(主键)、在何时执行什么样的任务、在工作流扭转的每个节点植入什么action、在实体变化的哪个阶段,触发什么样的action等业务语义,然后系统就通过架构将对业务开发人员更为友好的业务元数据表述转化为系统元数据描述,进而转化为相应的DDL,并创建相应的系统业务处理线程及工作流节点并创建相应系统行为的触发器。
现在看来很多元数据描述模型,我所知道的,包括ofbiz, hibernate都是使用技术语言来对元数据进行描述,而没法做到使用业务语义直接描述元数据。
对于普通业务开发人员而言,无需了解底层的架构,不需要了解外键是什么、主键是什么、系统线程如何调度、数据库表有哪些列、表和表之间如何进行关联等技术语言,而只需要了解并向系统表述清楚是什么样(对象A是否包含,包含几个对象B或反之)的关联(外键)、使用哪几个字段来唯一确定一个业务对象(主键)、在何时执行什么样的任务、在工作流扭转的每个节点植入什么action、在实体变化的哪个阶段,触发什么样的action等业务语义,然后系统就通过架构将对业务开发人员更为友好的业务元数据表述转化为系统元数据描述,进而转化为相应的DDL,并创建相应的系统业务处理线程及工作流节点并创建相应系统行为的触发器。
现在看来很多元数据描述模型,我所知道的,包括ofbiz, hibernate都是使用技术语言来对元数据进行描述,而没法做到使用业务语义直接描述元数据。