md5 是 hash 算法，不是随机数算法

@reus 你要把所有的接口定下来， 那就意味着你要做出很多假设， 而且这些假设会有依赖关系， 一旦其中的一个假设改变， 那么会导致一组假设全部失效，那也就是说你的接口全需要改。

需求是确定的，但是开发员人对需求的理解是随着开发慢慢增加了， 你期望别人在项目开发前就理解全部的需求并且不产生任何误解，我能想到的也只有简单的 CURD 了

@reus 想多了， 你数据不按照页面的需求给， 前端不得骂死你？一个展示页面需要调用三个接口来组装数据？后端可以把接口设计的尽量通用，但是前端的复杂度就上升了。

WEB 层和页面耦合那是必然的，WEB 存在的意义就是展示页面。

我们要避免的是核心业务对象和展示层的耦合

前端先写静态页
后端先设计表结构

然后就一个具体的功能点二者一同开发，这样后面的联调就比较简单了

@reus 一个需求可以有 N 种实现，具体选哪一种是由开发人员，开发进度共同决定的，并不是说需求定好了， 代码基本也确定了

优化前： 数据库查询 100ms 拼接字符串 10ms 开发人员耗时 0 min 测试人员耗时 0 min
瞎优化： 数据库查询 100ms 拼接字符串 12ms 开发人员耗时 30min 测试人员耗时 30min
真优化： 数据库查询 100ms 拼接字符串 8 ms 开发人员耗时 3 h 测试人员耗时 30min

@gsj987
感谢你的回复，我下去也看了 UOW， 发现一个问题

UOW 的核心是对对象的状态标记， 如果 被修改， 被删除之类的。

我找一个图， 可以帮忙说明一下吗？

https://imgur.com/HePiXYq

@gsj987

类似于 Mybatis 这种半自动的 ORM， 如何实现 UOW 中的隐式更新？

@Boywus 你提到 ‘这个用户’， 既然精确到用户级别，那么数据量应该不多吧？只有在用户被选中的情况下才提供详细的分页信息

@kimchan 我说的是维护一个总数量的计数，如果是 where 的计数，性能太差的话就不要做了， 直接给个下一页按钮，如果没数据了就提示没数据就好了

@gsj987

Application 更不应该关心持久化的问题

repo.update(ar);

应该是 repo 唯一暴露的更新接口，不存在显式操作

@ChoateYao
Domain Server 不应该关心持久化的问题吧
一般都是直接调用
repo.update(ar);

我的问题是 repo.update 如何实现？

单独维护一个计数表很难吗？

计数表又不一定准确，每次更新主表的时候发送一个事件更新计数表

跨进程通信
https://www.jianshu.com/p/c1015f5ffa74

@matsuz 因为 jdk 和第三方库都把常见的功能给实现了，有很多第三方的服务，比如说内存数据库都有纯 java 的实现，而且性能也不差。

@matsuz java 的依赖管理是我用过最好的，fatjar 了解一下

@hoosin 或者是内嵌一个 groovy 引擎？

@hoosin
考虑一下 el 表达式？
或者 eval 之前做过滤？
或者可以设置 js 执行引擎的权限？

直接调用 JavaScript 执行引擎？