回到面向对象最初的初衷, 而不是将面向对象写成流程处理模式的事务脚本.
如果你的业务 CURD 能 hold 住用 CURD 的事务脚本模式也没啥问题!
DDD 需要较高的成本, 而且再没有任何基础设施的情况下, 很容易写偏.
不过它的战略模式还是很有用的, 对大部分项目都有一定的参考价值.
我们使用 DDD 写过几个项目了, 框架使用的是 ABP, 团队也在自己重现构建内部 DDD 框架.
主要是团队的人都习惯了强事务一致性的事务脚本, 将多个模型的操作糅合到一个 Service, 导致 Service 变成了大杂烩, 越来越难以维护, 最终不得不研究使用 DDD 做切分, 后来又不得不上 CQRS, 前期阻力比较大, 现在再稳定维护期后, 大家就很爽, 添加功能也变得比原来容易多了.

如果有大量的字典类型的需要处理的, 可以使用 easydict, 最好还是将数据清洗一下, 这样效率高一点
import json
from easydict import EasyDict;

genre_movie = '{"genres":[{"id":28,"name":"动作"},{"id":12,"name":"冒险"},{"id":16,"name":"动画"},{"id":35,"name":"喜剧"},{"id":80,"name":"犯罪"},{"id":99,"name":"纪录"},{"id":18,"name":"剧情"},{"id":10751,"name":"家庭"},{"id":14,"name":"奇幻"},{"id":36,"name":"历史"},{"id":27,"name":"恐怖"},{"id":10402,"name":"音乐"},{"id":9648,"name":"悬疑"},{"id":10749,"name":"爱情"},{"id":878,"name":"科幻"},{"id":10770,"name":"电视电影"},{"id":53,"name":"惊悚"},{"id":10752,"name":"战争"},{"id":37,"name":"西部"}]}'

movies=EasyDict(json.loads(genre_movie)).genres
genre_ids = [80, 9648, 53]
genre_names = [movie.name for movie in movies if movie.id in genre_ids]
print(genre_names)

机器学习本质上就是拟合分布, 你需要保证你需要预测的数据符合分布. 因此机器学习只能预测共性, 没法预测它没学到的未知的东西, 而测量恰好就是未知数据! 我之前也研究过给雷达点云按照历史数据预测不存在的点来尝试补齐物体的轮廓, 后面发现效果不好, 没啥用, 纯粹属于浪费时间和算力!

@ray5173 你要补上的目的是什么干什么? 机器学习又不是什么魔法, 这种拟合出来的数据没啥用

你最好将数据先全部先备份,数据库以页为存储, 索引和页数据都在页上, 我怀疑物理某些页在磁盘扇区上物理损坏了.

@theklf4 做旁路有太浪费了, 有啥大的毛病没有?

@theklf4 什么配置, 出不?

@FrankHB 他去看源代码, 当然任何实现细节都会被发现!

另外你说的 Spring 的抽象设计在它的体系中是没啥问题的! 官方团队即便重构大差不大还是这个样子, 除非需求发生了重大变化, 软件设计就是尽量让代码贴近需求的自然抽象, 越是自然, 则未来越是容易维护和扩展!

@BlackZhu 如果你的项目中, 你无法搞清楚抽象的目的, 就不要抽象. 每个人都只能试图看的稍微远一点, 预测非常永久的事情纯粹是赌运气. 抽象是有代价的, 你需要了评估你项目的复杂度, 没有一个放之四海而皆准的办法, 设计就是平衡矛盾的需求, 平衡的好, 就是有效设计.

因为计算机科学中, 没有什么问题是通过添加一个抽象无法解决的, 如果不行, 就再加一个抽象. 所以后来有了: 如无必要、勿增实体. 而什么是必要就是一个哲学问题了! 每一个添加的抽象都是为了某个切面需求概率的抽象.

@hazardous 这的确是一个重要考量, 简单资源的盗链目前就在不能修改源的情况下只能使用 iframe, 另外 OP 说的为什么浏览器不能判断是你随意引用别人的内容, 别人也很容易攻击你, 信任是双方的! 我引用的第三方内容在被动态加载到本地化, 在未来完全可能通过修改 DOM, 然后诱导用户输入保密信息, 然后将信息提交到一个第三方从而欺骗你的网站用户, 让网站用户以为是 A 网站自身的行为,. 网页浏览器的普通用户并没有那么高的判断能力!

因为它本来就应该死循环, 设计上这样写就应该死循环!

你自己是销售吗? 这些应该是领导和公司销售需要考虑的问题, 归属于市场部管, 如果你是做技术的, 那很难转进去, 这个行业都是熟人相互介绍, 相互引进, 许诺关系费用, 一环套一套.

我们的设计原则是: 全部小写, 然后使用-分隔, 不需要 value 参数, GET /config/system-maintaining, 很多国际互联网企业的 API 也是这个规范, 另外并不是所有的 API 都适合 RESTful Style, 使用动词风格也没啥大的缺陷

@amuyue 如果你使用 UUID 作为主键, 然后需要频繁的查询, 可以使用有序的 UUID 生成器算法, 这种算法可以保证随着时间递增, 从而避免 UUID 默认无须导致的索引更新时候到性能损失, 如果查询非常频繁, 更新很少, 那就无所谓!

你的代码非常奇怪, 一般在 EF Core 中, 正常的写法是
public class Entity: IEntity{
public string Name{get;private set;}
public virtual Point{get;private set;}
}

很少使用 GetXxx 或者 SetXxx 的形式, 另外导航属性默认是懒加载的, 虽然你也可以将其调整为直接加载, 一般还是要手动 Include 的, 接口完全可以定义属性哈

你的代码非常奇怪, 一般在 EF Core 中, 正常的写法是
```csharp
public class Entity: IIterface {

}
```

@ungrown 放弃了, 懒得这特了, 主要是 Mac 连接 Linux 问题太多, 我需要 CUDA 加速查看 PointCloud, 这个没有硬件加速会非常卡, 操作起来极度不流畅, 画面传输的软件在内网还可以, 但一旦跨国(我的 Linux 服务器不在大陆), 就会非常看, VPN 和机场我都测试过了, 延迟是无法接受的, 我现在不折腾了, 重新在家里搭了环境. Linux 的桌面环境我是收购了, 我 10 前用的时候就问题多多, 10 年问题还是多多, 所以我还是只打算使用它的 bash shell, 彻底放弃它的图形, 不想折磨自己, 不是 ROS 这个破软件, 我早就放弃了折腾图像界面了!