后端技术面试38讲
李智慧
同程艺龙交通首席架构师,前Intel&阿里架构师,《大型网站技术架构》作者
立即订阅
4026 人已学习
课程目录
已更新 37 讲 / 共 38 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 掌握软件开发技术的第一性原理
免费
软件的基础原理 (8讲)
01丨程序运行原理:程序是如何运行又是如何崩溃的?
02丨数据结构原理:Hash表的时间复杂度为什么是O(1)?
03丨Java虚拟机原理:JVM为什么被称为机器(machine)?
04丨网络编程原理:一个字符的互联网之旅
05丨文件系统原理:如何用1分钟遍历一个100TB的文件?
06丨数据库原理:为什么PrepareStatement性能更好更安全?
07丨编程语言原理:面向对象编程是编程的终极形态吗?
答疑丨Java Web程序的运行时环境到底是怎样的?
软件的设计原理 (14讲)
08丨软件设计的方法论:软件为什么要建模?
09丨软件设计实践:如何使用UML完成一个设计文档?
10 | 软件设计的目的:糟糕的程序员比优秀的程序员差在哪里?
11丨软件设计的开闭原则:如何不修改代码却能实现需求变更?
12 | 软件设计的依赖倒置原则:如何不依赖代码却可以复用它的功能?
13丨软件设计的里氏替换原则:正方形可以继承长方形吗?
14 | 软件设计的单一职责原则:为什么说一个类文件打开最好不要超过一屏?
15丨软件设计的接口隔离原则:如何对类的调用者隐藏类的公有方法?
16 | 设计模式基础:不会灵活应用设计模式,你就没有掌握面向对象编程
17 | 设计模式应用:编程框架中的设计模式
18 | 反应式编程框架设计:如何使程序调用不阻塞等待,立即响应?
19 | 组件设计原则:组件的边界在哪里?
20 | 领域驱动设计:35岁的程序员应该写什么样的代码?
答疑丨对于设计模式而言,场景到底有多重要?
架构的核心原理 (13讲)
21丨分布式架构:如何应对高并发的用户请求
22 | 缓存架构:如何减少不必要的计算?
23 | 异步架构:如何避免互相依赖的系统间耦合?
24 | 负载均衡架构:如何用10行代码实现一个负载均衡服务?
25 | 数据存储架构:如何改善系统的数据存储能力?
26 | 搜索引擎架构:如何瞬间完成海量数据检索?
27 | 微服务架构:微服务究竟是灵丹还是毒药?
28 | 高性能架构:除了代码,你还可以在哪些地方优化性能?
29 | 高可用架构:我们为什么感觉不到淘宝应用升级时的停机?
30 | 安全性架构:为什么说用户密码泄漏是程序员的锅?
31 | 大数据架构:大数据技术架构的思想和原理是什么?
32 | AI与物联网架构:从智能引擎到物联网平台
33 | 区块链技术架构:区块链到底能做什么?
不定期加餐 (1讲)
加餐 | 软件设计文档示例模板
后端技术面试38讲
登录|注册

20 | 领域驱动设计:35岁的程序员应该写什么样的代码?

李智慧 2020-01-06
我在阿里巴巴工作的头一年,坐在我对面的同事负责开发一个公司统一的运维系统。他对这个系统经过谨慎的调研和认真的思考,花费了半年多的时间开发,终于开发完了。然后邀请各个部门的相关同事做发布评审,如果大家没什么意见就发布上线,全公司范围统一推广使用。
结果在这个发布会上,几乎所有部门的同事都提出了不同的意见:虽然这个功能是我们需要的,但是那个特性却是不能接受的,我们以往不是这样的……
最糟糕的是,不同部门的这个功能和那个特性又几乎不相同。最终讨论的结果是,这个系统不发布推广,需要重新设计。
这个同事又花了几个月的时间尝试满足所有部门的不同的需求,最终发现无法统一这些功能需求,于是辞职了……
他离职后,有次会上我们又讨论起这个项目为什么会失败,其中有个同事的话让我印象深刻,他的话的大意是:如果你对自己要开发的业务领域没有清晰的定义和边界,没有设计系统的领域模型,而仅仅跟着所谓的需求不断开发功能,一旦需求来自多个方面,就可能发生需求冲突,或者随着时间的推移,前后功能也会发生冲突,这时你越是试图弥补这些冲突,就越是陷入更大的冲突之中。
回想一下我经历的各种项目,似乎确实如此。用户或者产品经理的需求零零散散,不断变更。工程师在各处代码中寻找可以实现这些需求变更的代码,修修补补。软件只有需求分析,并没有真正的设计,系统没有一个统一的领域模型维持其内在的逻辑一致性。功能特性并不是按照领域模型内在的逻辑设计,而是按照各色人等自己的主观想象设计。项目时间一长,各种困难重重,需求不断延期,线上 bug 不断,管理者考虑是不是要推到重来,而程序员则考虑是不是要跑路。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《后端技术面试38讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(9)

  • 搞怪者😘 😒 😏 👿
    老师可以提供一下领域模型的例子吗,光看这个有点不懂
    2020-01-06
    9
  • leon
    公司是不需要程序员的,公司只需要能创造价值的人。大龄程序员的优势是他不仅仅是一个程序员了,他更是在某一业务、某一领域内的领域专家,而且知道如何用技术去解决实际问题,创造价值。
    2020-01-11
    5
  • Geek_22cbf4
    这一章,真的是感受到了理解层面的难度,或许当我对某一领域有了完全充分的理解,并参与了类似的模型设计,才能更好的理解理论层面!
    2020-01-06
    1
    3
  • Zend
    记得在老师的一篇文章中说好的程序员的工作效率是一般程序员的10倍甚至更多。好的程序员不仅代码写的漂亮,可维护性强 ,面对需求变动时能更从容面对。那如何做一个好的程序员 我想对领域的理解,对需求的理解 ,具有一定的前瞻性思考,适时提出自己的建设性建议,通过代码让公司的业务系统可持续发展,推动公司业务的增长。

    作者回复: 👍

    2020-01-08
    2
  • Paul Shan
    事务脚本模式的特点在于状态都在数据库里,业务逻辑在service层,业务逻辑与状态完全分离。
    领域对象模型,特点是聚合状态和操作,提供相对独立的模块和类。领域的模型的对象之一是实体,有唯一标识,实体被销毁前标识不变,能通过标识获得,实体的状态会变化。领域的另外一种对象是值对象,状态在生命周期内不变,因而更简单。领域对象因为有状态可以表达更为丰富的关系。但是设计好的领域对象依靠的主要不是技术而是对业务的理解。大龄程序员选择的业务领域的余地还是越来越小的,可能人老了就是这样。

    作者回复: 👍

    2020-01-16
    1
  • 靠人品去赢
    其实这个贫血模型,应该指的是Dao一类的吧,就是一个存值取值的一个东西,没啥逻辑。最后都是交给service处理,不关心业务逻辑,扩展会导致增加service,万一要做什么新的扩展关于dao导致别的service也要考虑。
    这个Service只管逻辑的也是贫血模型吗?充血模型有什么比较好的最佳实践吗?
    2020-01-15
  • Haan
    大龄程序员 除了基本的技能之外,需要扎根于某一特定的领域。right?
    2020-01-14
  • 山猫
    第一次听到DDD这个东西还是在一年前,仔细了解后发现,其实这个早在学习软件工程的时候就被提及。简单地说,就是针对某个领域,从功能或者组件的角度去进行对象的设计。

    另外关于 35 岁的问题,我认为除了要保持学习能力外,还需要有系统架构能力和丰富的经验,同时还需要了解经济、历史、政治,锻炼自己的社交和口才。

    作者回复: 👍

    2020-01-08
  • 唐二毛
    老师,我在DDD 的实践过程中,遇到两个问题: 1. 业务逻辑包含在Aggregate A中,而业务逻辑往往需要查询多个其他aggregate , 但是 Aggregate 又不能用 @Autowired 的方式来注入service/repository, 所以我的做法是首先将依赖的aggregate 查询出来,再作为参数传入到处理业务的aggtegate A中,感觉这种做法并不是很好,因为查询aggregate B 的参数也是业务逻辑的一部分,所以无法真正将业务逻辑收在 Aggregate A 里面, 希望老师指点一下!
    2. 我们的aggregate 关联链条很长,A -> B-> ... -> G , 并且,业务逻辑中往往需要用到这些关联的数据,如果用@ManyToMany的方式,就会使得 Aggregate 特别大,查询效率也很慢,还有就是循环依赖的问题,以前的做法都是用一个中间关联表来记录,但是这样好像是面向表编程,按照DDD,应该怎么设计呢? 如何在Aggregate 中来实现这些业务逻辑呢?
    2020-01-06
    4
收起评论
9
返回
顶部