@frank1256 DDD 的好处是通用语言可以保持业务一致性(这个就是第一道门槛, 越复杂的项目中, 很多术语大家没有天然形成共识, 是需要需求方, 业务专家, 开发者多方探讨, 最终达到一致性的: 说人话就是对同一个概念大家表述的是同一个东西, 这一点小项目看不出来啥优点, 但项目越复杂, 概念就会越不清晰). 子域(领域上下文)会强迫你思考如何将不相关的业务的实体分离到不同上下文, 这样你就没办法使用强一致性的方式直接操作这个对象, 而是必须去思考如何平衡 CAP. 另外他也会让你逐步学会思考使用关系模型(E-R)构建的面向对象模型是否合理, 如果你一开始就是使用的 MongoDB 这种数据库, 你就会更加深入理解对象的相互引用关系(引用即依赖, 依赖是重度耦合, 会带来很多问题). 这个话题太大, 不是几句话就可以说的清楚的....

@frank1256 可以多多交流, 我现在按照 DDD 这套写了也快 5 年了, 蒙蔽的地方还是很多, 但目前刚好能 HOLD 住现在的项目的复杂度. 如果你的项目不是长期维护, 使用 DDD 写是不值得的.

回到面向对象最初的初衷, 而不是将面向对象写成流程处理模式的事务脚本.
如果你的业务 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 的, 接口完全可以定义属性哈