V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
22yune
V2EX  ›  程序员

有没有一种基于领域模型驱动显示设计与业务逻辑开发的系统?在这个系统中,定义模型是通用的语言;模型的显示可以适配显示引擎,如使用不同的前端技术、主题、样式;模型的业务逻辑也可以自动适配执行引擎,如使用不同的后端语言。

  •  
  •   22yune · 2019-12-27 10:03:00 +08:00 · 2310 次点击
    这是一个创建于 1823 天前的主题,其中的信息可能已经有所发展或是发生改变。
    第 1 条附言  ·  2019-12-27 14:21:29 +08:00
    将模型定义语言与 XML Schema 类比,XML 的结构通过 XML Schema 来定义,业务模型也通过这种语言定义。XML 的显示可以根据 XML Schema 中的语义显示,能显示 xml 的内容,但内容的样式是通过 XML Schema 来匹配的,如属性一种样式、子元素另一种样式。通过模型通用定义语言定义的模型,显示时也就是由定义语言的语义来显示。这种模式符合驱动显示设计。如何驱动业务逻辑?将定义语言做成类似指令集驱动模型的互动?
    第 2 条附言  ·  2019-12-27 23:13:06 +08:00
    class 与 jvm 就是一种类似形式
    12 条回复    2019-12-29 10:32:12 +08:00
    noreplay
        1
    noreplay  
       2019-12-27 10:11:45 +08:00
    感觉 微服务+前后端分离,数据驱动页面展示+rpc/mq 与语言无关 似乎可以满足要求
    fanfou
        2
    fanfou  
       2019-12-27 10:50:44 +08:00
    我也一直有楼主这个疑问,我目前通过 UML 建模,然后写一些解析器,将模型基于模板转换为代码。但这样只能解决一些 CRUD 的简单接口及界面,面对复杂逻辑就无能无力了。
    22yune
        3
    22yune  
    OP
       2019-12-27 11:03:20 +08:00
    @noreplay 我想的是一种通用的模型定义语言,用这种语言定义模型后,前后端都可以基于模型做实现。你说的跟我想要的不一样,没有抽离业务模型。比如,用 java 写一个对象,对象里有属性与业务方法,用这个对象表达一个模型。我想要前端能根据这个模型做设计,后端可以用 jvm 执行方法,也可以用 node 执行。
    passerbytiny
        4
    passerbytiny  
       2019-12-27 11:11:32 +08:00
    无。

    你对通用语言的理解有严重偏差,Vaughn Vernon 中对通用语言没有给出明确的定义,但提到了这几点:是团队共享的语言,团队即包括开发者,也包括不搞开发的领域专家;通用语言在团队范围内使用;通用语言不是万能语言;通用语言和限界上下文存在一对一的关系;如果你试图将某个通用语言运用在整个企业范围之内,或者更大的、跨企业的范围内,你将失败。大体来说,通用语言虽然名字上有“通用”两个字,但那是内部通用,不是全局通用,换个团队或者换个限界上下文,就是另一套语言。

    连最基础的通用语言都不是全局通用的,再往上面的模型、架构更不可能全局通用,所以是做不出来你需要的开发系统的。领域驱动设计,应该算是理论方面的科学,不是实践方面的工程学,是没办法批量造轮子的。
    passerbytiny
        5
    passerbytiny  
       2019-12-27 11:15:27 +08:00
    @22yune #3 理论实践是相互影响的,同样的,理论层次的模型,跟实践层次的 Java、node 代码,也是相互影响的。你这种完全脱离代码的纯理论性质的模型,设计出来是不会有用的。
    22yune
        6
    22yune  
    OP
       2019-12-27 13:34:23 +08:00
    @passerbytiny 我说的模型通用定义语言意思是定义领域驱动设计中语言的语言。 将模型通用定义语言与 XML Schema 类比,XML 的结构通过 XML Schema 来定义,业务模型也通过这种语言定义。XML 的显示可以根据 XML Schema 中的语义显示,能显示 xml 的内容,但内容的样式是通过 XML Schema 来匹配的,如属性一种样式、子元素另一种样式。通过模型通用定义语言定义的模型,显示时也就是由定义语言的语义来显示。

    我的思绪也不清晰,我想说下面的话,下面的话逻辑可能是没有的。
    我见过一种开发平台,录入数据模型,基于字段名和类型就能生成默认页面。数据模型有哪些字段有哪些一对多关系,会对应到显示样式。数据模型中有指定状态字段、主键就能生成对应的后台 CURD 代码。
    我认为这种平台就接近这样的系统了,只是它的模型定义是固定的,比如模型中可以定义状态字段、主键,如果要再加一种类型的字段,并不明确。
    22yune
        7
    22yune  
    OP
       2019-12-27 14:03:17 +08:00
    @passerbytiny #4 “连最基础的通用语言都不是全局通用的,再往上面的模型、架构更不可能全局通用”可以做不是完全通用但绝大部分情况可用的吗? #6“我说的模型通用定义语言意思是定义领域驱动设计中语言的语言。”就是你上面说的意思“在通用语言只上的模型”。我想能不能只支持可见的情况,或者能不能让模型的解释权放开,或者模型是自解释的,或者定义的是形式(形式是通用的吧?)
    22yune
        8
    22yune  
    OP
       2019-12-27 14:11:43 +08:00
    @22yune 指令集是一种语言,基于这个上面有非常多的高级语言。(模型定义语言是一种语言,基于这个定义的模型就是业务的语言) 这个能借鉴吗?情况是有什么不同?
    crclz
        9
    crclz  
       2019-12-28 22:54:32 +08:00
    "模型的显示可以适配显示引擎,如使用不同的前端技术、主题、样式":DDD 与 CQRS 关系很深。你写的模型(聚合)其实是 C 的模型( Command ),而你通常需要额外写为 Query 写模型,并用原始 SQL 的方式(而不是 Repository )来填充这些模型。
    如果你的 C Q 模型差距不大,那么请考虑 CURD 而不是 DDD
    22yune
        10
    22yune  
    OP
       2019-12-29 08:33:52 +08:00
    @crclz 我想要能适应各种行业的业务系统。都说是 curd。都感觉是重复劳动。我希望定义模型是通用的,这样就可以开发出通用的前台显示引擎与后台逻辑引擎。像这种行业业务系统把业务模型描述出来就能出产品了(基础版、主题版)。
    crclz
        11
    crclz  
       2019-12-29 10:02:58 +08:00
    如果是 CURD 的话,那么"Asp.Net Core MVC"或者"Asp.Net Core Razor Pages" 能满足你的需要。
    你只需要专注于定义数据表模型(class),然后可以很轻松的自动化生成数据库表、自动化迁移 schema ;还可以自动生成 增、查、删、改页面,搭配有 bootstrap,样式都给你调好了,方便在各种设备上查看。还有基于 Role 的开箱即用的权限管理系统(方便省事,但可定制性不强)
    教程:
    https://docs.microsoft.com/zh-cn/aspnet/core/tutorials/razor-pages/?view=aspnetcore-3.1
    22yune
        12
    22yune  
    OP
       2019-12-29 10:32:12 +08:00
    @crclz 感谢回复!
    你说的很像,有生成前后端。只是你描述中只定义了数据模型,没有把业务模型抽象出来。其它方面限制也太大。我新开了一个问题,请查看 https://www.v2ex.com/t/633251#reply0。换了一种应该是对我问题更明确的描述。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2898 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 22ms · UTC 00:34 · PVG 08:34 · LAX 16:34 · JFK 19:34
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.