领域驱动设计DDD

最近看了领域驱动设计,斗胆粗浅聊聊我的看法:
1. DDD演进了三层架构presatition-Application层(也可以叫service层、逻辑业务层BLL层)-DAL层(也可以叫Infra等),由于application层逻辑过多,后期维护容易像面条一样缠在一起,数据耦合混乱,引入DDD层 依赖反转将数据流清晰,开发熵增慢。对于这一层的设计,将外部所有依赖都反转依赖DDD层,对层的设计,延伸出来了很多概念,entity-value object-domain service,用来定义DDD层的零件;aggregate-factory-repository用来规范对象的增(factory)删改查(aggregate)与持久化(repository)。
2.架构通过文件系统(文件夹、命名)以模块化的形式展现,对应到具体的实践,DDD层以domain文件夹声明,domainService以命名*Manager声明等。
2.业务演进模型会变得更加复杂、为了将层与层、模型与模型之间(拆分出界限)之间进行区分,又引入了限界上下文-上下文映射-域等概念;层与层之间需要通信,通过共享内核(shared)、防腐层(ACL)等进行通信。
4.架构有很多书籍、很多架构形状,本质都在说同一件事情:引用《整洁架构的》观点,基于多态实现抽象接口,实践依赖反转的原则,忽略外部细节。
5.架构设计-架构模式-设计模式,维度层层变小。DDD、整洁架构等一类思想启蒙类、内在审美类的书籍归类架构设计;微服务-六边形等属于具体的架构模式,是对思想和设计的实现;设计模式指的是GoF 23种设计模式又是具体架构模式的局部细节抽象,维度就更低了。
#牛客AI配图神器#
全部评论

相关推荐

在AI时代,我认为刷leetcode还是很有必要的。我们首先要搞清楚为什么公司要考察我们写算法题,其实本质就是看会不会写代码和代码风格命名规范以及考察计算机四大件408中的数据结构。AI 确实能帮我们生成算法题的解题思路,甚至直接写出完整代码,但面试官要的从来不是 “能写出答案”,而是解题过程中体现的逻辑思维和工程素养。你让 AI 写一道动态规划题,它能给出标准答案,但你要是说不出状态转移方程的设计思路,解释不清为什么要这么定义 dp 数组,面试官一眼就能看出你是 “抄作业” 的。刷 LeetCode 的核心,不是背题,而是锻炼把复杂问题拆解成小步骤的能力 —— 这种能力是 AI 替代不了的,也是程序员安身立命的根本。对咱们 Java 后端程序员来说,刷 LeetCode 更是和日常工作息息相关。你刷过的链表题,对应着项目里 Redis 的链表结构底层;你吃透的哈希表题,能帮你更好地理解 HashMap 的扩容机制;你练熟的多线程题,更是和 JUC 并发编程直接挂钩。这些底层逻辑的理解,不是 AI 给一段代码就能悟透的,必须靠自己一道题一道题地敲、一遍又一遍地复盘才能掌握。而且大厂的算法面试题早就不是 LeetCode 原题了,很多都是结合业务场景的自创题。比如让你设计一个订单号生成的算法,既要保证唯一性又要提高生成效率;或者让你优化一个高频查询的缓存淘汰策略 —— 这些题没有固定答案,需要你结合数据结构、性能优化等知识综合分析。AI 或许能给出几个方案,但它没法帮你权衡不同方案的优劣,更没法帮你解释为什么这个方案最适合当前的业务场景。还有很重要的一点,刷 LeetCode 能帮你养成良好的编码习惯。变量命名是否规范、代码是否有注释、边界条件是否考虑周全、异常情况是否处理得当 —— 这些细节都是面试官考察的重点。AI 生成的代码有时候会为了追求简洁而忽略这些细节,而你在刷题过程中刻意养成的习惯,会直接体现在你的项目代码里,这才是真正的竞争力。说到底,AI 是工具,刷 LeetCode 是修炼内功。工具可以帮你提高效率,但内功不足,再好的工具也发挥不出作用。在 AI 时代,刷 LeetCode 不是没必要了,而是更有必要 —— 它能帮你区分开 “只会用工具的程序员” 和 “真正懂技术的程序员”。
AI时代还有必要刷lee...
点赞 评论 收藏
分享
评论
1
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务