• 李威
    置顶
    2023-01-12 来自湖南
    请教钟老师,持久化“员工聚合”的方法(EmpRepositoryJdbc.save(Emp emp))中会存在性能问题不,比如员工有10个技能,10条工作经验,10个岗位(这个数量级在现实中应该还算是合理的),要保存员工记录再加上这30条记录,那这一个持久化操作就会产生31条 insert into 的 sql 语句,数据库压力会不会太大。 另外,以后如果再增加员工兴趣啊,员工荣誉证书啊,员工职业资格证书啊,等等,那这个“员工聚合”的持久化操作可能就要上百条 insert into 的 sql 语句了,这个怎么解。 当然,确实可以优化一下持久化的方法逻辑,比如将所有 insert 语句组成一条批量 insert 语句,这样所有数据的保存就一条 insert 语句搞定了。但是随着不断在“员工聚合”中添加要保存员工兴趣之类的需求,那这个“员工聚合”的持久化以及数据库查询操作所涉及的数据可能都会比较多,这里会不会是个性能隐患。

    作者回复: 这是个典型问题,非常好。如果真的发展成你说的样子,建模成一个大聚合就不合适了。可以考虑把“工作经验集合”本身作为一个聚合。这样把聚合拆开。

    共 3 条评论
    7
  • 燃
    2023-01-11 来自浙江
    1身份证号,在对象内部充血实现检验逻辑即可。根据上面的评论设置员工信息的时候根据身份证号自动装填性别生日等属性也可以写在对象内部,比如如果生日属性为空,根据身份证号自动补全。 2改变员工状态应该放在empHelper,因为员工状态的改变肯定不是员工自己做的,所以放对象内部不合适,是组织调整员工状态,但是组织设置员工状态的职能不属于组织这个对象的主要职能违反单一职责,所以用empHelper,需要调整员工状态的对象,引用这个helper是比较解耦的做法

    作者回复: 第一问,考虑身份证号本身就是领域对象。同样,第二问,考虑员工状态本身就是领域对象。

    
    2
  • py
    2023-02-16 来自上海
    1. 要看怎么校验,如果是非法输入等检验 放在领域对象里,如果要查表检查有效性,要放到领域服务里 2.员工类的领域对象

    作者回复: 1 还有一种选择是把身份证号本身作为一个领域对象,然后把规则放在这个对象自身 2 考虑为员工状态本身建一个领域对象

    
    1
  • escray
    2023-01-30 来自北京
    为什么 emp 包是在 orgmng 包的下一层,如果是平级会不会看上去更容易理解? 对于思考题, 1. 如果要对身份证号进行校验,如果只校验格式,那么可以放在实体里面(员工类),如果需要在数据库里面查询是否有重复的情况,那么可以放在领域服务里面? 2. 改变员工状态的业务规则,可以考虑在领域服务中放一个接口,调用员工类中的实现。 看到留言回复里面说到将身份证号和员工状态当做领域对象,一开始感觉这样操作,领域对象好像有点多了,但是后来发现,是为了值对象做引子

    作者回复: 面向对象熟手的一个标志就是会用一些小对象。关于人员和组织的包结构,取决于建模时的模块划分。

    
    1
  • Geek_97eefa
    2023-01-12 来自广东
    老师春节会断更吗?

    编辑回复: 编辑代答,春节不断更,但不更新正课,一方面让老师更充分地准备后续内容,一方面也给还没跟上学习进度的同学多点学习时间。春节时,我们会特别策划几期加餐,敬请期待。

    
    1
  • 杰
    2023-04-03 来自广东
    这个课程有代码仓库地址吗?

    作者回复: https://github.com/zhongjinggz/geekdemo 目前放出了迭代1的,后面的正在逐渐补充

    
    
  • AngryShoes
    2023-03-13 来自湖南
    第二条总结: 关于技能和工作经验的两条规则,必须从整个聚合层面才能验证,所以无法在 Skill 和 WorkExperience 两个类内部实现,只能在聚合根(Emp)里实现。 请教下钟老师如果Skill 和 WorkExperience 是业务实体(Entity)的话,校验规则可以放在实体内部吗?

    作者回复: 可以的,前提是这个规则只在本实体内部。

    
    
  • acmookey
    2023-03-05 来自广东
    说一个不重要的问题,跟着老师的思路敲代码时,发现好像 Emp中判断WorkExperience的时间是否重叠的逻辑貌似有问题,遂百度了一下,这样表达可能会更准确 !( otherStart.isAfter(thisEnd) || otherEnd.isBefore(thisStart) )

    作者回复: 两者逻辑上应该是等价的

    共 2 条评论
    
  • 邓西
    2023-01-30 来自四川
    1. 通用的基础方法,可以放在领域服务中,common; 2. 从聚合根Emp移到EmpRepository中,统一管理修改状态和修改动作。

    作者回复: 1 可以考虑建立一个“身份证号”的领域对象,把逻辑放进去 2 考虑一下建立一个“员工状态”的对象,把逻辑放进去

    
    
  • Johar
    2023-01-25 来自重庆
    1. 如果要对身份证号格式进行校验,这种逻辑放在哪里比较好? 放在员工类里面,因为身份证号是员工的一个属性 2. 在目前的程序里,改变员工状态的业务规则是在员工类中实现的,你觉得放在哪里会更合适? 目前放在员工类即可

    作者回复: 考虑一下身份证号和员工状态本身也可以是领域对象。

    
    