获得徽章 7
强烈推荐这本21年出版的“Learning Domain-Driven Design : Aligning Software Architecture and Business Strategy”。
如果你是领域驱动设计的初学者，只看一本书的话推荐看这本。如果你对领域驱动设计有所学习，并且也在实践中尝试过，但依然对其有诸多疑问，那么也推荐用这本书重学一遍。如果你认为自身对领域驱动足够了解，但在实践领域驱动设计时依然有很多 trade off 的内容说不清，那么推荐这本书重学一遍。
这本书好在哪里？就两点：说的清楚明白的同时删繁就简。清楚明白对比的是Eric Evens 自己的书。删繁就简对比的是“领域驱动设计模式、原理与实践”。
基本上把 DDD 的东西5、6个章节就全讲完了，而且让人醍醐灌顶，很多似是而非的概念，三言两语说不清的内容，落地就需要 trade off 的内容，基本在这5、6章都说清了。当然我不确定我是否是因为量变到质变。但如果我在6、7年前就看到这本书的话，可能都不需要这么多量来换质。对，这本书就是这么好，你看完之后就不用在浪费时间在其他DDD内容上了，实操去吧，你已经会了！
后续章节融合了很多 DDD 提出之后架构与模式的演进与 DDD 的结合，可以说非常与时俱进了。
最后中文版貌似叫：领域驱动设计学习手册。如果你看中文版，我建议可以先查查 domain、context 的英英词典，不要轻易地理解为：领域和上下文，会有一定帮助。后知后觉，这两个词用的很精准，但普遍的翻译是缺失了背后的含义的。
如果你是领域驱动设计的初学者，只看一本书的话推荐看这本。如果你对领域驱动设计有所学习，并且也在实践中尝试过，但依然对其有诸多疑问，那么也推荐用这本书重学一遍。如果你认为自身对领域驱动足够了解，但在实践领域驱动设计时依然有很多 trade off 的内容说不清，那么推荐这本书重学一遍。
这本书好在哪里？就两点：说的清楚明白的同时删繁就简。清楚明白对比的是Eric Evens 自己的书。删繁就简对比的是“领域驱动设计模式、原理与实践”。
基本上把 DDD 的东西5、6个章节就全讲完了，而且让人醍醐灌顶，很多似是而非的概念，三言两语说不清的内容，落地就需要 trade off 的内容，基本在这5、6章都说清了。当然我不确定我是否是因为量变到质变。但如果我在6、7年前就看到这本书的话，可能都不需要这么多量来换质。对，这本书就是这么好，你看完之后就不用在浪费时间在其他DDD内容上了，实操去吧，你已经会了！
后续章节融合了很多 DDD 提出之后架构与模式的演进与 DDD 的结合，可以说非常与时俱进了。
最后中文版貌似叫：领域驱动设计学习手册。如果你看中文版，我建议可以先查查 domain、context 的英英词典，不要轻易地理解为：领域和上下文，会有一定帮助。后知后觉，这两个词用的很精准，但普遍的翻译是缺失了背后的含义的。
展开
1
6
近两年较频繁的出现在海外开发者社区中的 Platform Engineering 看下来，很像是国内早前，又建又拆、大兴土木的中台...... 当然可能更接近 Platform Engineering 的应该是基础架构部。
据 Gartner 报告显示 2022 年约有 45 % 大型软件研发团队拥有自己的 Platform Engineering Team，预计 2026 年这一数字会达到 80% 。这个数字有一点令我意外的，我本以为海外的大型软件研发团队应该早就有接近 90% 比例会有这样的团队。但也有可能诸多企业早就有这样的团队，但是 Platform Engineering 这个概念落地的比较晚，才造成了这个差异。
据 Gartner 报告显示 2022 年约有 45 % 大型软件研发团队拥有自己的 Platform Engineering Team，预计 2026 年这一数字会达到 80% 。这个数字有一点令我意外的，我本以为海外的大型软件研发团队应该早就有接近 90% 比例会有这样的团队。但也有可能诸多企业早就有这样的团队，但是 Platform Engineering 这个概念落地的比较晚，才造成了这个差异。
展开
评论
1
剔除 LLM 相关的 AI 及其衍生内容，似乎近 2 年在系统架构与工程领域没有什么掀起风尚的内容。排除那些明显带着浓郁的左倾思想的部分。我所了解到的相对较 “新” 的内容，像是 Cell-based architecture 和 Domain storytelling 多少有些新瓶装旧酒。
一个可以看作是微服务架构的一种实现风格，但是不见得会步入研发团队的生产实践，利好的场景比较有限，同时盲目借鉴必然会导致复杂度进一步上升。不过，我也发现 Data plane 和 Control plane 的架构风格似乎成了当下普遍的叙事。
另一个可以认为是 Event storming 的替代，本质上还是对于 DDD 在战略层面落地的实践工具。
欢迎大家评论留言讨论，在工作或业余时间关注、使用到的新技术领域内容![[抱拳]](//lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_120.6c3effe.png)
一个可以看作是微服务架构的一种实现风格，但是不见得会步入研发团队的生产实践，利好的场景比较有限，同时盲目借鉴必然会导致复杂度进一步上升。不过，我也发现 Data plane 和 Control plane 的架构风格似乎成了当下普遍的叙事。
另一个可以认为是 Event storming 的替代，本质上还是对于 DDD 在战略层面落地的实践工具。
欢迎大家评论留言讨论，在工作或业余时间关注、使用到的新技术领域内容
![[抱拳]](http://lf-web-assets.juejin.cn/obj/juejin-web/xitu_juejin_web/img/jj_emoji_120.6c3effe.png)
展开
3
1
当我们在 
mvnrepository.com 仓库中查询到某个冷门依赖，但是项目中引用依赖后，却提示诸如此类 “Could not find artifact xxxxxx in central (repo.maven.apache.org)” 错误，导致无法下载对应依赖。
可通过如下图-1所示方式，获取 jar 包下载地址，之后添加到项目根目录下 pom.xml 文件中，添加相关 repository 设置，即可解决依赖下载问题。
mvnrepository.com 仓库中查询到某个冷门依赖，但是项目中引用依赖后，却提示诸如此类 “Could not find artifact xxxxxx in central (repo.maven.apache.org)” 错误，导致无法下载对应依赖。可通过如下图-1所示方式，获取 jar 包下载地址，之后添加到项目根目录下 pom.xml 文件中，添加相关 repository 设置，即可解决依赖下载问题。
展开
评论
4