@leonleung @whooami 写了一些文章，来介绍一下思路。

可视化组件拆解系列(二) - 契约通信
https://mp.weixin.qq.com/s?__biz=MzkwODUyNDEyMQ==&mid=2247483747&idx=1&sn=6f30997073e15ee69a7a9306a1cba0f6&chksm=c0c9ee55f7be6743cca8e7d5679881a8b21d84eff22526b4247daa680e96fca7ac400e9d09f0&token=1426599149&lang=zh_CN#rd

@leonleung 如果感兴趣，我后面就写一些系列的文章，来说下自己的一些考量吧

@romisanic 的确如此，相信依旧还是很多人，会走同样的路。这种思维惯性，有时候就无意识的

@xiaochena 其实，我也觉得些 json 比较繁琐，所以，做了一个声明式的描述。其实，开发只要维护好这份组件声明即可。差不多是这样，其他其实跟平时开发业务代码没有区别
https://github.com/akoomitech/round_lottery/blob/main/src/imk-component/ProductCardList/imkdef.js

@Secrexy 是的。 这个商业逻辑， 可能作为开发者， 从未遇到或者考虑过。以为仅仅只是开发出产品就够了。只是产品可能仅仅只是很小的一部分，更大的是，如何商业化的流程上的考虑

@Secrexy 的确是如此。 程序员的思维惯性， 很容易陷入到打磨产品的舒适圈里，而不是将时间放在如何连接用户和销售上。

@wzy44944 当前公司并不是用这个产品，只是技术的理念是一样的。 一个是基于 Vue 技术栈，但是，目前自己开发的是基于 React 技术栈。 我后面其实打算出一个开源版本，如果用私有化部署，有源码，使用自己的服务资源的话，应该就不会有太大的顾虑。

@oouz 我们目前是直接开发一个商品组件。公司内部有商品的系统， 在这个组件里面去请求这些商品数据， 商品组件可以在搭建的时候，透出一些可编辑的选项，可以是商品 ID ， 商品的分类等等， 那么， 通过商品组件以及搭配可编辑的选项，就能做到很多的商品展示的场景了。按业务需求来做定制

@sdjl 时间也不会倒流，可能， 这些体悟可能让其他人少走点弯路吧

@zhaodong 是的，我们目前的业务就是整合到整个公司的业务链条中的。这样你就快速搭建出商品营销、优惠券营销，大促营销等等一系列，完全属于整个公司自己的业务。而不是，简单的内容展示。 所以说，这个产品只有在 B 端集成才能发挥价值

@overthemoon 完整的产品， 服务端前端都有

@xuld 你是什么团队啊

@MeteorVIP 都这么说了，算是吧😂 但是，最终还是想拿到一些结果的吧

@TabGre 这不是原型工具，是直接成型的页面

@henryhu 的确是如此。 即使是真实的需求， 找到合适的场景， 也才会产生价值。如果，你看到了需求， 但是，选错了受众，这样的需求也就成了伪需求

@ASHENONE123 可能是因为自己想做完，也许是希望，也许是热情吧

@zzNaLOGIC 你可以理解为，你将平时需要开发才能完成的业务，做成了一套可以搭建的组件。也就是，将你们的业务代码，转换成了一套可以可视化组装起来的组件库。里面没有其他第三方平台的代码，我们做的只是，帮你们把业务通过搭建的方式组装起来。

@zzNaLOGIC 是的， 这个很中肯。 现在运营已经有足够多的工具可以使用了。 主要就是这件产品，能否整合内部的流程，比如集成内部的商品系统，内部分群系统，优惠券系统，权限等等，快速的搭建生成跟自己业务紧密结合的系统，形成一套完整体系。这样的搭建工具，才会促成业务快速产生价值。而目前我们也是如此做的，也的确看到了价值。但是， 这样的系统，必然逃脱不了每个公司的集成定制化需求， 如果将搭建的能力抽离出来，在集成方面做到快速可扩展，才是这个产品的价值。但是，to B 这块东西，独立开发很难弄，除非你先走开源让他们先用起来，才能慢慢切入

@RealJacob 这也是最迷惑人的地方， 明明看到这个东西也有价值了， 但是， 你拿出去之后，就未必可行。这其中的玄学就很多了， 但是，主要还是自己在诸多方面都很不足吧