2020-01-06老师可以提供一下领域模型的例子吗，光看这个有点不懂 9
2020-01-11公司是不需要程序员的，公司只需要能创造价值的人。大龄程序员的优势是他不仅仅是一个程序员了，他更是在某一业务、某一领域内的领域专家，而且知道如何用技术去解决实际问题，创造价值。 5- 2020-01-06这一章，真的是感受到了理解层面的难度，或许当我对某一领域有了完全充分的理解，并参与了类似的模型设计，才能更好的理解理论层面！ 1 3
2020-01-08记得在老师的一篇文章中说好的程序员的工作效率是一般程序员的10倍甚至更多。好的程序员不仅代码写的漂亮，可维护性强 ，面对需求变动时能更从容面对。那如何做一个好的程序员 我想对领域的理解，对需求的理解 ，具有一定的前瞻性思考，适时提出自己的建设性建议，通过代码让公司的业务系统可持续发展，推动公司业务的增长。作者回复: 👍
2
2020-01-16事务脚本模式的特点在于状态都在数据库里，业务逻辑在service层，业务逻辑与状态完全分离。
领域对象模型，特点是聚合状态和操作，提供相对独立的模块和类。领域的模型的对象之一是实体，有唯一标识，实体被销毁前标识不变，能通过标识获得，实体的状态会变化。领域的另外一种对象是值对象，状态在生命周期内不变，因而更简单。领域对象因为有状态可以表达更为丰富的关系。但是设计好的领域对象依靠的主要不是技术而是对业务的理解。大龄程序员选择的业务领域的余地还是越来越小的，可能人老了就是这样。作者回复: 👍
1
2020-01-15其实这个贫血模型，应该指的是Dao一类的吧，就是一个存值取值的一个东西，没啥逻辑。最后都是交给service处理，不关心业务逻辑，扩展会导致增加service，万一要做什么新的扩展关于dao导致别的service也要考虑。
这个Service只管逻辑的也是贫血模型吗？充血模型有什么比较好的最佳实践吗？- 2020-01-14大龄程序员 除了基本的技能之外，需要扎根于某一特定的领域。right？
2020-01-08第一次听到DDD这个东西还是在一年前，仔细了解后发现，其实这个早在学习软件工程的时候就被提及。简单地说，就是针对某个领域，从功能或者组件的角度去进行对象的设计。
另外关于 35 岁的问题，我认为除了要保持学习能力外，还需要有系统架构能力和丰富的经验，同时还需要了解经济、历史、政治，锻炼自己的社交和口才。作者回复: 👍
2020-01-06老师，我在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 中来实现这些业务逻辑呢？展开 4