@lostberryzz 简单说就是使坏和厚黑。
使坏包括上面举例的，开发时不好好做，能露脸就积极表现。
我觉得无脑附和领导、甩锅、夸大话等不负责任的表现是厚黑。

同感 但#23 #24 #25 说的问题确实存在，会有合适的解决方案吗？可以思考一下，感觉弄出来了会是技术性网络社交的突破—：）虾扯蛋

@stormgo
部分 v2er 好像有些误解。我们现在是用业务模型描述业务。我思考的是‘一种模型定义规范‘，用于描述业务模型的，不是描述业务的。需求的是抽象描述业务模型的语义。你说的情况就是现在大部分的情况——定义一个数据模型，真正的业务逻辑用各种其他语言实现的（如 java、Python ）。我希望设计一种通用的业务模型定义的规范（或语言）（带业务逻辑的）。基于这个规范定义的业务模型，就可以用不同的前端、后端技术去解释模型。绝大部分的情况基于规范就可以有默认的解释，应该要支持调整。现在的语言，语义都是确定的。这个业务模型定义语言我希望是抽象的形式（比如包含、主从），可以用多重语义（现在是前端显示与后端逻辑）。 看了上面回复列出的各种已有产品（都是同一种意图，可能真是在寻找银弹）不太成功的现状。我有点怀疑这种定义业务模型的语言是否能抽象出来或抽象出来是否有意义（支持简单情况的抽象是可以的，支持上面说的低代码开发平台 通用化）。
MPS 还在了解，感觉对这个问题有帮助。

@luozic 感谢回复！
模型变化是常规场景。如果对模型定义的规范抽象出来了，对模型的定义肯定在这个范围内，变化也是定义过程。‘解释器’ 如果是通过生成代码再通过代码对应的解释器运行的话，代码要再生成一遍，就像 java 写的类修改后要重新编译一样。

@reself '银弹'只是像现在这样听说过，我不知道这个想法是不是银弹，我更希望是像现在的包管理和构建工具一样是一种好的实践。用美妙的想法将现有的东西结合成整体的创造。

@CODEWEA 感谢回复！
你说的可能是对的，你问的就是我的问题。业务模型的抽象我想大家都是没问题的，我是想更进一步对模型的描述的抽象。就用 JAVA 对象表示的模型的描述的抽象就两种：属性、方法。越抽象应该形式会越少。换个问法：模型的描述都有那些形式？

@lihongjie0209 重要的是不再像现在这样重复，bug 不用重复改，特性不用重复实现。每种技术实现一遍就够了。就像
@takemeh #39 说的，做更有意义的工作，不重复、发挥创造力。

@lihongjie0209 业务系统里有业务模型这个应该是自明的。我主要的问题就是把这个模型表达抽象出来，能抽象出来就能'翻译'，否则就是没抽象出来。所以你的问题就是我的问题，不要反问我了。
你说的叫法倒是无所谓，他们的工作内容应该会是不一样了。从主要编码变成主要描述业务模型。

@cedoo22 最终应该还是不同技术的代码，'处理器'是另一个层面的解释器或者说可能是代码生成器，处理器支持的语义多一点，模型定义就更丰富一点。抽象出形式，使形式能复用。处理器就能解释成各种具体技术实现。

@FeifeiJin
@gowk
是的 基于这种平台的启发，想更进一步的方法。我在形式上看到了可能，简单情况可能就是这种平台的通用版。我在思考一种可扩展、通用规范的实现方案。

@cedoo22 感谢回复！
你说的是我类比中表达的意思。
只是这么做是行不通的，因为用 JAVA 写的还是面向对象或面向过程的思维方式。我想的业务模型定义更多可能是声明式定义（也有面向模型的过程）。这样写出来的 JAVA 代码是没办法反向出业务模型的。就算能反向也不行，这个模式转换太复杂。我想的是基于业务模型的定义即用于显示也用于驱动业务逻辑，就像你说的 servlet 一样。我想要的是通用的，servlet 不是通用的。

@WildCat 感谢回复！看了一点，虽然 model 中有基础的 curd，但感觉跟其它语言的框架（上面有些回复说的）思想或方法类似。

@cedoo22 感谢回复！你说的 lombok 和 jsr 我接触过（不喜欢 lombok ）。我想的是一个 class 经过 jvm 能解释成前台显示也能驱动里面的方法。或者经过不同的 jvm，有些解释成某种的前端显示，有些是另一种前端显示，有些是某种后端技术（包括持久化支持），有些是另一种后端技术。

@676529483 是的 我也感觉最大的难点可能就在于基于模型的业务逻辑表达抽象。

@hantsy 感谢回复！我的想法与 mda 非常类似，甚至可以说一样--模型驱动。我粗略看了一下，mda 的模型与我设想的不太一样，我想的模型包括业务逻辑，逻辑基于模型之间的关系，与显示相关的也应该是模型内部的形式。
就像指令集基于几种类型的指令就可以完全表达各种各样的程序过程，我思考有没有可能基于模型表达业务逻辑的类似指令集（不一定是指令，可能是一种声明，指令我觉得有一种过程性的动作含义），如果能建立，那模型表达应该会是明确的清晰的。如果业务逻辑不是基于模型的，或者定义规则复杂难明的，我理解会出现你说的生成代码形式的问题。

@3dwelcome 额。。感谢回复！但我觉得你说的话 好像某种模式----那种没有实际内容的

@loading 安全可能是个问题。但现阶段还在思考可行性，安全性还未做考虑。我觉得这个场景下安全性对可行性不会造成阻碍。

@22yune 就像是主题一样 细节可以改 但标准的或者说 典型的能默认适配。

@vultr
我是希望能细节形式标准化，同一种形式的细节不用为这个业务实现一遍，为另一个又重复实现。