“阳春三月初，满枝迎春新花栖木，天留片片白云风上住；孩童推门去，又放纸鸢笑声满路，手中长线没入天尽处；”——司南 《春三月》
契机篇，谈到如果业务系统的场景适合产品工厂模式，要说服相关方启动产品工厂项目，则要说清楚产品工厂的收益，但不同的产品工厂建设模式，以及对于产品工厂的理解层次，能够得到的收益差异会很大，所以我们先把收益这个问题放放，来展开下具体的产品工厂的细节。
喜欢杭州一年四季绿色盈盈的样子，媳妇对家里楼下路边的景色尤其满意，闺女从小学放学后往西走到小河边绕路回家的那一段，更是百走不厌。河边的景色忽明忽暗，竹林疏密相间的从头顶掠过，若是遇到下雨，苍翠欲滴的感觉跃然心头。路到半途可以望见学校里的羊圈，是真的羊圈，他们学校里有好几只羊，运气好的话，羊会给你个好眼色，赏赐两眼。最初知道这几只羊的时候，只要有机会去学校里面，都会去投喂一下他们，后来习惯了，不再新鲜了，也不再那么钟情于这几只羊了。
现在我们讨论产品工厂所能够装配出来的产品，是什么样子的，产品的构成要素包括哪些。说清楚这个问题，我们才能去进一步的推敲，不同的产品要素，需要用什么样的技术，来实现配置化。
我们使用时间遍历的方式，来模拟推演一个产品的完整生命周期，以此来看在产品生命周期的每个阶段，是谁，在什么时间，做什么事情。然后我们看看这些阶段里，产品工厂可以做什么，能够做到什么地步。需要说明的是，我们只是用这种方法来进行一次推演，推演的结论，并不是让你来直接用于自己的产品工厂建设的。即便是我自己，也可能在完成推导后，进行裁剪和选择性实现。说到这里，忍不住唠叨一下，TOGAF对于架构方法论本身的可裁剪机制阐述，真是狗，怎么说他都对，笑死。不过我们这里说的进行裁剪，并不是为了达到TOGAF的可裁剪给自己带来的进退皆可的效果，而是希望告诉正在本系列的文章中徜徉的同行者，你有自由选择的权利，而且必须要进行选择性实现，不要理想主义。
在写到这一段的时候，卡了很长时间，为什么呢？当时我在想，如何能够比较全面而系统的阐述，一个复杂一些的产品生命周期全过程，进而尽可能的涵盖全部的产品要素，或者选择一个简明的产品生命周期，但是这样会不会显得不够专业？最后让我自己想通该如何写的，是开篇我们所说的：“不会拘泥于形式，也不会刻意的去总结拔高我们的建设效果”，放下要装13的执念，放下如果写的不够复杂不够专业就会有损形象的无稽之谈，放心大胆的搞。
先来一个简单的吧，大家容易理解，我也容易讲述，可能这个最简单的，才是我的真实水准，加油。
零、引入：从Spring Bean的使用模式说起
在后端开发的世界里，Spring是老朋友了，在系统中遍地都是，对于Spring的Bean，随着时间的发展，也从最初的XML配置方式，逐步的过渡到了@Service，@Component @Bean这样的注解方式。曾经对于注解的转变，一个常见的说法是，XML配置太麻烦了，既然代码用JAVA写完了，在类上加一个注解就能够作为一个Bean不是更好么？
然后大家就开始通过这种快速的方式，来使用Bean了。
但是，不知道有没有人遇到过，一个Bean要在不止一种场景中使用，而且这两个Bean要能够区分开，并且不能是一个对象实例。这个时候，使用注解就需要注意了，你突然发现原先简介的注解，开始需要增加name或者其他唯一标识字段来说明实例ID了。注解开始变得不那么简洁。
继续下去，终有一日，你会发现，JAVA中能够被复用的代码，能够被复用的Bean，在多个复用场景中，需要有自己的参数配置，也就是类属性，来专门为这个场景服务。这个时候，注解是无力的，回到Spring发端的XML配置方式，你发现这种配置方式可以没有任何障碍的配置出这种复用关系。
至此，Spring Bean的设计理念才算清晰，曾经自以为的Bean声明的用法，其实连真正的可复用Bean，可能都算不上。一个只用实例化一次，在各种场景下无差异存在的代码块，不是复用的真正形态，这只是复用的最初级阶段，比把代码抄来抄去好那么一点。
一个真正可复用的Bean，必定会对复用场景下的特定需求做出回应与设计，也一定会有自己的属性配置能力，在这样的条件下，Spring Bean的XML方式能够将这种能力完全发挥出来。也许，这才是Spring设计者最初对于Bean的设计思考吧。
等等，Spring Bean的配置能力，跟我们前面讨论的主题，产品工厂，有什么关系？看似八竿子打不着啊？在我看来，产品工厂的本质，是业务抽象与配置便利化。既然产品工厂与配置便利化有关系，Spring Bean的配置化能力当然与产品工厂有关系了。
如果你用过将一段代码功能封装为一个具备属性配置能力的Bean的这种形态，恭喜你，你已经在用一个极简版的产品工厂了。
产品工厂的最初级形态，你已经见过了。那我们可以来用稍微严谨些的描述来定义一下这个阶段了。
一、混沌初开：后端代码组件化
在建设业务系统的过程中，将能够复用的后端代码块封装为可复用的组件，这些组件有不需要进行配置的，有需要进行配置的，对于需要配置的，通过Spring XML等方式来实现其配置能力，提供给不同的场景。各场景可以通过调整组件的属性配置，改变组件的行为。
之所以将后端代码组件化，作为单独的一个阶段来说，不仅仅是因为他好理解，还因为他事实上构成了后续所有的高级阶段的运行基础。无论后续我们在之上叠加了多少复杂功能，后端JAVA代码总要能够运行吧，能够灵活装配吧，缺了后端运行时的灵活性，整个产品工厂就会成为无根之木。
问题1：后端代码组件化是不是只能通过Spring XML配置来实现？
当然不是。Spring XML本身就是一种全能但是原始的配置方式，我们可以借助于Spring基础框架的能力，或者在XML配置的基础之上，构建可视化的配置界面，比如通过WEB前端来进行Bean配置，比如通过IDE插件来进行Bean配置。
后者，通过IDE插件来进行Bean配置，正是2008年代时，当时的各类金融科技公司开发平台的建设思路，源起IBM Eclipse，IBM在自身的企业级开发平台上诞生了众多的图形化配置能力与编程能力，而国内的各种公司也诞生了自己的开发平台，普元，宇信，易诚，赞同科技，信雅达等不再一一列举。这些平台在当时给新入行的我，以极大的震撼，原来程序可以这样写？不仅征服了一众开发人员，也征服了一众科技领导，这可是重要的生产力提升呀。
十年之后，金融业在众多可视化开发平台的爆炸图里挣扎（以易诚EMP框架为例，一个复杂的业务流程，超过200个图元很正常，我把这个称为爆炸图，几乎不能看，已经失去了可维护性），互联网各大厂早已把微服务玩出了花，阿里巴巴中台化也至臻成熟（成熟的意思，后面就是从顶峰跌落了）。
不知道大家有没有疑问，为啥微服务不需要更高级的配置化、IDE、产品工厂等高端能力？答案是，互联网里好多人没见过在业务设计上的高端玩意。能够知道远古一代产品工厂，并把简化版抄一抄的，已经算是人中龙凤。另外，在互联网的高迭代下，产品工厂这种大国重器，互联网没有时间来沉淀和长期演化这些玩意。
扯远了，对于更广范围的一些论述，我们后面有其他篇幅来搞。先收一下。说回Spring XML配置能力升级，在此基础上，你用IDE方式来配置，或者用WEB前端来配置，都是一个不错的升级版。
配置完成的Bean，只要你能够存储为XML文件或者什么形式，然后加载的Spring的容器中，则从配置到运行的环节，你就打通了。
问题2：如果我不是JAVA怎么办？
产品工厂与JAVA没有必然联系。君不见对于业务能力和技术能力的封装，从C语言时代就有了呀，回顾下恒生电子最初一代的GAPS平台，就是在C平台上进行组件化和界面配置化呀（虽然GAPS从未说过自己和产品工厂有瓜葛）。致敬下伟大的开拓者，现在回头看，在当年的一片暗夜之中，创立GAPS这种开发平台，其软件工程理念以及技术能力，不是一般的牛，此处只能佩服。不能以我们今天的技术能力和难度来评估曾经的当时。
甚至于说，产品工厂这个词，本来就不是由JAVA领域产品产生的，JAVA领域的人，没有这么高级的思维，能搞出产品工厂如此高级的东西。产品工厂的溯源，在于汽车生产的代际升级，在于金融领域业务大牛的天马星空（无贬义），唯独与JAVA没有什么关系。
老旧的COBOL系统是否够实现产品工厂？没有问题。C编写的系统，是否可以实现实现产品工厂？没有问题。产品工厂的核心理念，在于业务能力的抽象以及业务可装配化，不在于具体的语言和平台实现。
但是，我这里说句但是。具体语言提供的支持不同，产品工厂实现难度有很大差异呀。
举个例子，业务抽象完了组件，要写组件代码吧，组件的相关描述和配置能力如何实现？组件是否能够实现自描述结构？是否能够实现天生的可配置能力？是否能够实现业务模型与技术模型的一致化？这里有好多问好。
传统语言存在不少限制，会提升产品工厂的实现难度，或者换种说法，会降低产品工厂整体架构的可维护性。比如在传统业务型语言COBOL下面，如果要搞产品工厂，可能只能搞信仰模式。
什么叫信仰模式？把业务产品定义和抽象的非常清楚，产品-组件-元件-条件等等，一层层拆解和定义，然后把这些值以单个值的形式在数据库中存下来。在代码中，通过产品ID以及组件ID等去读取这些属性，然后使用。业务可以清晰的看到产品所有的要素，但是对于开发就比较惨，读参数还是读参数，一个个的读参数，读到你吐血。并且因为这种模式，其缓存等也会成为一个问题。
读取数据库时，因为读取一个产品的参数需要很多行，需要很多的SQL来慢慢搞，读取进来后进行内存里面的装配等动作。实在是痛苦至极。
为啥搞产品工厂需要这么痛苦？我将产品的原子属性作为一个独立的数据行放在数据库中有什么好处？如果不这样存储会怎么样？这些问题的可能的答案，是我们前进的动力。
好这个问题说了大概七成。产品工厂可以不用JAVA，也可以与JAVA无关。但是先进的语言能力，带给产品工厂是脱胎换骨的提升。从纯信仰模式，到白菜消费品的模式转变，语言平台不可或缺。
我们在这里收住。假定我们已经可以完成后端代码的组件化了。
一个业务系统，是不是只有后端代码组件化就够了。看你做的是什么系统。如果这个业务系统对外提供的服务能力，只是后端能力，以服务接口的方式向各个关联方提供服务，那后端代码组件化之后，这个平台就很爽了。通过后端代码组件化干完了这个业务系统的所有的活，这样的系统，在金融系统中，以通道类系统为主，比如银行典型中间业务平台，外联平台，综合前置系统等，也就是对应GAPS，EMP，AFE的能力覆盖范围。所以当年他们才那么火啊。
对于非纯粹的前置类系统，就不是那么简单了。我有操作界面啊，我还有业务流程审批，甚至还有其他业务规则需要进行配置呢。你就只给我搞个后端业务代码组件化就完事了？多年前，比较务实的回答可能是：拿这些平台来搞后端逻辑，然后前端单独开发，业务流程单独开发，搞定。
嗯嗯。也不错。流程审批有流程引擎，他有自己独立的配置能力和想法；前端么，后来慢慢有低代码平台，也开始可以拖拉拽了。不少科技人士看到新兴的低代码平台，一片兴奋，这是有多么的没见识，20年前的VB，Visual Stduio，Delphi等产品，早已玩烂了呀，说句不好听的，比现在的还强大，可惜只是本地可视化而已，但其设计理念与深度非常足。一堆没有新意，甚至于说没有打穿核心业务的低代码平台能够横行，也说明了这个行业从业人员的水平，不能说菜，只能说是极端的菜，技术视野是真的窄。没见过世面，还是不要在科技领域丢人的好。
这样说人家其实不太好。毕竟低代码平台也实实在在的在特定场景下做出了很多成绩了。我们不否认低代码平台的价值，但是把低代码无脑吹成万能，无脑崇拜低代码三个字，是不可取的。如果只凭借组件化与配置化或者可视化能力，就能够冲出重围，那现在应该是.Net平台和Visual Studio的天下。但很显然，我们看到了事实，不是这样的。
但是可以看到的是，前端，后端，流程领域，各自发展出了各自一堆的配置化与组件化能力。那前端领域，如果说低代码这个方向，可能有点问题，那具体是什么问题？或者解法可能是什么呢？
在我看来，前端低代码化的代价极大，而且不能打穿核心业务。所有以无代码为核心的平台，差不多都站不住脚，一边说自己使用方便，不需要学习代码，一边说自己什么都能干，和纯写代码的能力是一样的。信息表达能力相同，其复杂度也是在一个数量级上的。这个是低代码或者一切以无代码为核心平台，无法解释和无法逾越的门槛。
你要想简单易用，就必须针对具体场景优化，提供便捷处理方案。只有经过特定优化，才能以更好的体验给用户。但是一旦极端易用，则其表达能力一定受限。这种表达能力受限，也不是今天才出现的，上一代的平台化产品都遇到过，至于解法么，简单粗暴，两点，第一：提供能够完全匹配代码能力的图元，比如分支，循环等图元；第二：增加一个自定义代码节点，随便写，可以把grovvy表达式等代码，直接贴到这个可视化节点中。
到这里就搞笑了。我们可以来一个看似非常简单的线，谁家的低代码平台或者配置化平台上出现了自定义代码节点，即可认为其理论体系的崩塌。别信他们说的各种天花乱坠的东西了，都有分支和循环了，都有自定义代码节点了，你还相信他们的配置搞定一切的理论？道心破碎只这一瞬间就够了。
倒回来说，代码至于这么让人讨厌么？低代码一个无法回答的问题是，以后大量的业务编码人员干嘛去？其中一种路径是：我们不追求百分百的低代码或者无代码，成熟能力通过配置和可视化，来进行简单重复，复杂能力，该写代码就写代码，把代码编写为新的组件。业务组件的增加，可以是通过代码来实现的，而不仅仅是低代码平台本身的代码是开发人员开发的。
基于如上论述，我们迎来第二个阶段，前端后端一体化。
二、倒反天罡：前端后端一体化
啥意思？搞前后端一体化不是历史的倒退么？我们前端演化了这么多年，搞了这么多理论能力和技术能力建设，才把前端后端给分离开，你咋论证了一堆产品工厂的事情，转头给了个再次一体化的结论？咋这么恬不知耻呢？
先不要骂，且听我娓娓道来。
如果我们假定低代码是一条死路，那么合理的路径可能是：常用和成熟的能力，通过配置和某种简单途径实现可视化，复杂能力该写代码就写代码。在这个假设下面，我们看看前端最常用的能力是什么？操作运营类系统简单点：表单展示，表格展示，操作向导。好像除了这些就没有了。面对终端客户的会复杂点，我们先不管。
对于表单展示，低代码平台常见做法是拖拉拽搞定。这样的方式，真的是最方便的方式么？可能不是吧。我就展示下一个数据表中的某一行数据，你让我们拖拽那么多的字段干嘛？还有没有更简单的方式？
有，既然数据表是已经定义好的，那我们对于表单的展示，是否可以基于数据表的描述来自动生成，而不用拖拉拽。理论上是可以的，在常用的JAVA领域，数据库表结构可以通过mybatis的插件转换为项目中的实体类。不过这个实体类缺少点更复杂一点的前端相关描述，比如中文字段名，以及字段提示，字段控件类型，字段校验规则等。
但是缺的这点东西，如果我们在后端都补充上，会怎么样。如果后端的实体类，不仅仅有后端进行数据表存取所必须的定义，而且还有前端展示所需要描述信息。是不是我们有办法收集和汇总这些信息，然后交给前端，让前端给直接渲染出一个表单出来？
答案是：可以的。不仅可以渲染表单，也可以渲染表格，而且渲染表格更简单。
有人可能要说，前端交互哪有这么简单，还有一堆码值，级联，关联动作等，都配置到后端代码中，成啥啦？先不要急，没说都要配置到后端代码中，我们只是提出一种思路，我们看看按照这个思路演进下去，会发生什么。
后端的实体类上的描述会变得非常丰富，因为后端必须在代码中，说清楚中文名，用途，备注，提示，以及控件类型，关联的码值类型，以及校验能力等。等等，这些东西，不就是我们在现在系统的开发中，经常丢失文档的东西么？某个字段的准确用途是啥，校验关系咋样，这些各种信息，没有准确的更新到文档中，没有集中的地方可以看，分散在各个地方，甚至数据库元数据管理平台也有部分，比如字段备注啥的，但是又可能不准。
假如这些信息，都是以一种集中的，标准书写方式，来写在了实体类里面，那对于这个数据表的描述，才真正的全面了。同时因为这些信息，会直接展示在界面上，备注都不敢乱写。看起来有点优点。
当然，前面提到的缺点，是一定有的，我在前端界面上，一个字段的值变了，后面某个字段联动咋办？或者一个字段变了，后面一堆字段统一隐藏咋办？我承认，这些问题是存在的，我也不打算在这个数据实体类的前端能力提升部分，来解决这些问题，我反对万能化设计，也必须要承认自己设计的机制不是万能的，而且这些机制，往实体类里面硬怼是没有意义的，不是不能实现，而是会非常别扭和变态。
但是抛开这些缺点不谈，我们找到了一种通过后端定义，快速建立前端界面的能力。这个机制不完美，但是估计升级一下，应对常规的操作运营类的需求足够了。而且够简单，建设成本很低，这就够了。
对于前端，需要建立一套机制，读取后端提供的某个数据表对应的表单或者表格的基础数据描述，来画出这个界面，也就是说前端变复杂了，变成一个渲染引擎了，后端带来的不再是纯业务数据，而是有表单基础数据描述用来绘制界面，再附带业务数据读取接口来获取业务数据，填充进前端界面。
而这个前端的能力，实际是跟后端分离的，也还是前端后端分离，前端技术栈需要使用比较新的。
到这里，我们的标题含义可以解释清楚了，所谓的前端后端一体化，不是指的前端代码库和后端代码库在一起，进行混合开发，而是将前端所需要一些后端业务要素的定义，从前端代码中抽离出来，在后端代码中进行声明式开发。这样后端代码中，既有业务逻辑，数据实体类，也有这些数据实体类的前端要素定义。
要完成完整的前端后端一体化，这里只是起步，要达到实用的地步，还要进行细粒度的拆解和建设。这些我们放到后面的其他文章中展开，本篇我们只完成思路讨论和切割划界。
三、拨云见日：业务流程可视化
前面我们具备了后端代码组件化，前端展示配置化，多个后端组件和前端页面就可以穿起来组成完整的流程。跟实际业务过程相匹配的业务流程出现了。这里的业务流程，不一定是审批流，可能是真实的业务流程，一个步骤一个步骤的推进。
对于业务流程的可视化，我们不需要那么麻烦，自己去想解决方案，因为这个领域独立发展和演进了很长时间了，产生了不少丰富的成果，支持BPMN标准的流程引擎，比较成熟。
所以我们在这里，采用业界流行的流程引擎，来实现业务流程可视化。比如flowable。而不需要自己从零开始设计底层机制。但是有几个要点需要注意和解决。
1、流程引擎的设计器还是太复杂了，需要拆解。
怎么拆解呢？流程引擎的设计器，是用来形成流程引擎可以执行与运行的XML配置文件的。包括流程有哪些节点，每个节点有什么配置属性等。不同的设计器，其复杂度和操作难度不一样，但整体而言，都非常难用。只能说流行的设计器，解决了规范化的问题，用标准的BPMN图元完成了流程设计。
为了提升易用性，BPMN的图只用来保留流程节点和基本属性即可。每个业务流程节点需要配置的其他属性，建议拆解和分离到其他地方，总结你需要的配置元素和能力，然后汇聚到业务组件中，通过后端业务组件的方式，来配置每个节点。
然后在运行时，流程引擎需要的相关参数等，均从业务组件中抽取。
2、流程与业务系统的关联性如何建立的问题。
传统的业务系统中，会配置好流程引擎的设计图，形成一个可视化流程后，将流程ID保存下来，如果业务系统需要启动流程，就把这个流程ID给作为参数传入，完成流程引擎的实例启动，并逐步推进后续的环节。
这里会存在一个问题，流程引擎跟实际的业务，脱节比较厉害。我们举一个例子，一个业务有多少个环节，这个定义关系，是不是仅存于流程引擎中？显然不是。一个业务流程的某个环节，是否只需要知道其可视化工作流上的属性定义信息？显然也不是。那其他信息的定义，是不是也需要这些业务流程的细节定义信息？是。那既然如此，就需要有地方，可以独立的定义这些业务流程以及业务流程的细节信息。
流程引擎，只是在业务系统用到流程引擎的时候，拿出来关联到这些业务流程定义上去的，用来表达需要通过流程引擎进行推进的一部分信息，比如审批信息等。
解决这个业务流程统一定义问题的，我们叫做业务建模。更精确一点，我们关注的是银行业的业务建模。银行业的业务建模包括数据建模，交互建模，流程建模，产品建模四大组成部分。
到这里，你可以看到，我们前面的部分，模模糊糊已经有了数据建模，交互建模，流程建模，产品建模的影子了。对的，这个世界就是这么奇妙，当你认真和实际的去推导一些事情的时候，其合理的推导结果，会和现存的一些理论产生高度拟合。
到这里就清楚了，对业务系统搞业务建模，产生业务体系的完整定义和描述。然后后端组件化，前端配置化，流程可视化等，均与业务建模的结果与定义严格关联。
完成这个关联之后，你会发现，结合业务的流程定义，你需要在某个特定业务流程上，先搞定流程可视化，基于流程可视化，对于每个流程节点，配置其审批能力配置，以及节点的展示页面（流转到这个节点时，用哪个页面来展示数据信息），以及业务组件信息。
看起来，我们已经能够通过业务建模，把前面提到的能力全部串起来了。到这里，我们几乎要完成产品工厂大集成了。
四、抽丝剥茧：产品工厂大集成
怎么就到产品工厂大集成了？前面讲了下后端组件化，前端配置化，流程可视化，接着就产品工厂大集成？什么鬼？别人的产品工厂里面的组件-元件-条件那么多东西，怎么在这里完全不存在呢？
没有搞错，确实走到产品工厂大集成了。想想我们文章开篇时所说的，本文主要来进行划界，产品工厂需要配置啥，各种配置成分，需要用什么方式来实现，那是不是确实讲的差不多了。后端，前端，流程，确实差不多了。
之所以你觉得突兀，可能是因为被某些产品工厂文章给洗脑了，一上来就给你说产品工厂中的产品是由组件，元件，属性，条件啥的组成的，讲解其定位与功能，那个是人家的设计结果，不是设计和推导思路，你拿着别人咀嚼过的东西，来倒着学习，只能学到用法，而不是推导分析过程。而我们最不重视这些，毕竟再好的设计，也会有改进和被替代的那天，对于天命之人，如果我们能给你提供些什么帮助的话，那一定是背后的分析思路与建设路程，而不仅仅是建设结果。
但是你说我们与那些完全没有关系，也不是，所以我们需要搞精细一些，说明在新的产品工厂中，那些传统要素咋办。
限定到JAVA领域，后端组件化实现后，一个后端组件，会有自己的可配置属性（properties），这些可配置属性的类型与定义能容纳很多信息，比如定义一个String类型的属性，可供定义的信息包括：1、数据类型；2、属性名称；3：属性默认值；4：属性注解。
如果我们数据类型选择简单类型（String，Int等），则可以认为这个属性是一个最终配置项，不存在子项。如果是一个复杂类型，这个复杂类型又包括了多个可配置属性值，则形成了后端可配置组件之间的嵌套关系。
既然能够嵌套了，则可以看到。我们充分利用JAVA语言本身的定义和语法能力，就可以描述一个复杂的层次化结构，这个层次化结构，应该完全具备描述产品工厂多层结构和复杂描述信息的能力。毕竟JAVA语言是一个通用语言，通用语言的表达的能力，毋庸置疑。
一些传统的产品工厂中的所有要素，我们在后端组件化搞定后，就能够完全表示出来了。而且搞定后，你会发现，这个产品工厂的某个具体产品，其在后端代码中，是一个面向对象的结构，而不是一片零散的键值对。这个产品，可以通过Spring的Bean加载机制，创建一个活生生的对象出来，然后用普通对象的访问方式，来实现配置参数读取。
而对于配置过程，前面说过了，对应于后端组件化，我们可以建立丰富的可视化配置能力，现阶段我们选择WEB配置界面，通过WEB配置界面来配置产品参数。WEB后管实现可视化产品配置，配置形成XML或者类的配置存储起来，系统启动时加载这些配置数据，形成Spring的Bean，可以供后端代码引用。就完整了。
原先传统产品工厂中，所不包括的前端界面，业务流程部分，我们认为也应该是产品工厂的部分。为什么呢？以汽车为例，你觉得产品工厂是需要产出一个发动机，还是一部整车？估计大家都有答案。传统一点的产品工厂，原先只聚焦于核心业务要素的定义，是在特定历史条件下的无奈举动，在新的阶段，我们已经具备了低成本的定义全要素产品工厂的能力，那我们就把一个业务系统的全部，都用产品工厂定义出来吧。
先定义产品基本要素，然后关联业务流程，在业务流程上定义前端要素，以及审批要素，而且这一切的背后，还有业务建模实现了完整业务的规范化定义。这样的产品工厂才让人放心。
五、返璞归真：再论技术选型
以上每个地方，都会涉及到技术选型等。本篇不展开细节，但是提出一个观点，这个观点就是：在现在这个技术日新月异的新时期，避免花费过高成本，打造太过于强大的平台，力图毕其功于一役。
为啥这样说呢？你的目标越高，成本越高，这里的成本包括人力成本和时间成本，随着平台变得巨大无比，进行维护升级以及统一协调会变得越来越难。而且随着平台越来越大，你对领导吹牛的PPT也会越来越夸张，以至于领导都会觉得，这样好的东西，不做大范围推广，简直就是暴殄天物。
这个时候灾难就来了。还记得我们喷低代码的时候，所论述的，如果一个东西要做到好用，则需要对特定场景进行打磨，既然是对特定场景进行了专门优化，则其通用性就会下降，把一个已经场景化定制过的平台，进行大范围推广，其结果可想而知。另外一个含义，一个平台进行大范围推广后，这个平台本身会接受众多的优化需求和升级要求，其自己的迭代可能会成为瓶颈（这里估计读者自己就能举出很多例子来）。
即便是，万一，我们说万一，这个大平台做的确实很好，也投入精力持续维护的很好。但是现在技术的日新月异大家也看到了，几乎10年一定是要技术体系大变的。那个时候，你这个平台再优秀，要不要进行底层能力升级呢？如果要，原先的业务系统资产怎么办？哪些能传承下去？要不要大规模重构？估计你已经有答案了。
既然技术体系的升级是不可避免的，大范围的通用是不可实现的，那么一个合理的取舍就出现了：在有限的业务覆盖范围内，通过集成当前主流技术迅速实现一个低成本的场景化产品工厂，是最佳选择。
具体到数字指标，可能用代码行数比较合适。现在先不给，等我们自己实现完之后，倒着来给大家一个参考指标。也不要笑话我没啥理论依据，我实话实说，总比给你一个不靠谱的拍脑袋数值来的靠谱。