获得徽章 9
在DDD中，千万不要认为领域模型最重要，其实应该是（应用层+领域层），在日常使用DDD开发时，你会发现，业务流程基本体现在应用层，也即是说，核心业务流程，由领域层和应用层共同完成。
应用层它是负责协同和编排的，调用仓储层存储数据库，调用其他聚合根或者内部RPC接口/外部接口，都是它干的。
在六边形架构或者洋葱架构中，需要把领域层和应用层，圈在一起的。
应用层它是负责协同和编排的，调用仓储层存储数据库，调用其他聚合根或者内部RPC接口/外部接口，都是它干的。
在六边形架构或者洋葱架构中，需要把领域层和应用层，圈在一起的。
展开
9
2
DDD中，controller层和基础设施层（访问数据库/访问外部RPC接口/Restful接口），需求新需求的到来，确实是容易变化的。
但其实，应用层也是经常变化的，按照DDD的理论，应用层是调度的，一旦有新需求，应用层是必改的。
因此应用层的的代码一定要清晰，有好的封装，这样就非常有助于提升交付需求的速度和质量。
但其实，应用层也是经常变化的，按照DDD的理论，应用层是调度的，一旦有新需求，应用层是必改的。
因此应用层的的代码一定要清晰，有好的封装，这样就非常有助于提升交付需求的速度和质量。
展开
评论
点赞
一般来说，还是尽量宽容一些，对于工作没几年的同事，如果他的能力暂时不太好的话，还是先给够空间，让其成长，而不是立刻把它优化掉。
像最近，我就让一个同事，只做【技术需求】，不做【业务需求】，因为他写的代码稳定性和清晰度都还不够，而一堆的坏习惯，做事手尾多。
通过不断的重构自己的代码，并做好code review，经过三周的努力，他进步的速度还是可以的。至少编程习惯好了蛮多了了。
像最近，我就让一个同事，只做【技术需求】，不做【业务需求】，因为他写的代码稳定性和清晰度都还不够，而一堆的坏习惯，做事手尾多。
通过不断的重构自己的代码，并做好code review，经过三周的努力，他进步的速度还是可以的。至少编程习惯好了蛮多了了。
展开
4
2
需求交付的，代码这块，就三个点：
第一点：代码稳定没手尾；
第二点：代码清晰；
第三点：代码扩展性；
先搞定第一点，它最重要。剩下的才是清晰度和扩展性。
对于新手，别一下子就想着三点全做到。
第一点：代码稳定没手尾；
第二点：代码清晰；
第三点：代码扩展性；
先搞定第一点，它最重要。剩下的才是清晰度和扩展性。
对于新手，别一下子就想着三点全做到。
展开
3
点赞
赞了这篇文章
不得不感慨现在AI生成代码的能力真的很强，就在刚才我问一下AI，如何基于java 17 + springcloud alibaba +DDD，实现一个扩展性强的多渠道下单接口，它生成的代码框架已基本满足了我的要求了。
可以这么说，只要你问的足够仔细和准确，AI生成的代码就越靠谱。
这在以前是难以想象的，如果你使用百度或者谷歌，根本无法把一大串的描述文字，扔给它，让它直接给你答案，你需要花很多时间去挑选搜索结果。而AI直接用一问一答案的方式，把结果直接告诉你。
效率一下子提升了很多很多。
可以这么说，只要你问的足够仔细和准确，AI生成的代码就越靠谱。
这在以前是难以想象的，如果你使用百度或者谷歌，根本无法把一大串的描述文字，扔给它，让它直接给你答案，你需要花很多时间去挑选搜索结果。而AI直接用一问一答案的方式，把结果直接告诉你。
效率一下子提升了很多很多。
展开
评论
2
为啥稀土掘金也开始了，标题党，讲原理，讲基础，讲知识点。
实际业务里，代码里应该如何实操和设计，一行都没有。实际遇到工作难题，你是怎么解决的文章，越来越少了。
实际业务里，代码里应该如何实操和设计，一行都没有。实际遇到工作难题，你是怎么解决的文章，越来越少了。
展开
3
点赞
有时候别怪面试官问你一些技术的底层细节。
因为【完全不懂】跟【懂了暂时用不上】，是两码事。从区分度来看，面试官就是会看看候选人平时自己有无去研究一些工作内容之外的技术点，不然你跟其他的候选人又有啥区别呢?
如果平时有兴趣研究一些平时暂时用不上的技术，这个候选人我觉得还是蛮不错的，对技术有兴趣。
之前团队里的一个同事，面试入职了小米，虽然他履历和学历都相当一般。但他平时就爱折腾一些技术，去小米面试的时候，面试官问不倒他，也就顺利入职了。
因为【完全不懂】跟【懂了暂时用不上】，是两码事。从区分度来看，面试官就是会看看候选人平时自己有无去研究一些工作内容之外的技术点，不然你跟其他的候选人又有啥区别呢?
如果平时有兴趣研究一些平时暂时用不上的技术，这个候选人我觉得还是蛮不错的，对技术有兴趣。
之前团队里的一个同事，面试入职了小米，虽然他履历和学历都相当一般。但他平时就爱折腾一些技术，去小米面试的时候，面试官问不倒他，也就顺利入职了。
展开
8
6
【程序员】：哇，这个客服页面如此复杂又丑陋，各种功能密密麻麻的堆在一起哦，能用?
【资深客服】：恩，这个是客服团队的【核心需求】，就得这么干。
【程序员】：页面不应该是错落有致，排版大气美观吗?
【资深客服】：那种除了好看，没啥用，完全不能提高操作效率。客服要的是【就在一个页面搞定所有事情】
之前语雀团队的玉伯要求团队的人必须【精通业务】，不然在专业领域里做东西，肯定栽跟头，说的实在太有道理了。在做到【好用】【操作效率高】之后，还能做到【好看】的，就真的厉害了。
【资深客服】：恩，这个是客服团队的【核心需求】，就得这么干。
【程序员】：页面不应该是错落有致，排版大气美观吗?
【资深客服】：那种除了好看，没啥用，完全不能提高操作效率。客服要的是【就在一个页面搞定所有事情】
之前语雀团队的玉伯要求团队的人必须【精通业务】，不然在专业领域里做东西，肯定栽跟头，说的实在太有道理了。在做到【好用】【操作效率高】之后，还能做到【好看】的，就真的厉害了。
展开
18
17
极客时间有很多付费的专栏和视频，如果要让我推荐一些课程的话，我倒是觉得【超级访谈】这个系列很值得去看。
对于工作比较多年的程序员，可以在这个系列里接触到一些技术思想、管理、产品、运营、业务、遇到大大事如何处理等一些知识。
对于工作比较多年的程序员，可以在这个系列里接触到一些技术思想、管理、产品、运营、业务、遇到大大事如何处理等一些知识。
评论
2
有时候考察一个程序员的功底怎么样，不是说，你算法、底层原理，设计模式的多熟练。而是程序出故障后，你做的功能是如何快速止损，快速补偿的。
比如说，依赖的第三方系统挂了10分钟，等对方系统恢复后，想把有问题的数据，重新推送。结果你没有写这种程序，又得写代码重新上线，又得非常辛苦的去找出数据。
这不行的。虽然it团队是需要快速交付，但是【大的程序设计思路】还是得有的。我这边总结的几个点就是：
第一，不要出大问题；
第二，万一出大问题了，能快速止损或者有补偿的工具。
不然就只能干瞪眼，等着IT的一把手，被其他部门的人，狠狠的挑战一波。
你代码可以写的乱一些，扩展性不好，关系都不大的。如果你写了一堆自以为很漂亮的代码，就沾沾嘻嘻，而系统出问题后，又手忙脚乱，毫无办法。那你还不如不写呢?
比如说，依赖的第三方系统挂了10分钟，等对方系统恢复后，想把有问题的数据，重新推送。结果你没有写这种程序，又得写代码重新上线，又得非常辛苦的去找出数据。
这不行的。虽然it团队是需要快速交付，但是【大的程序设计思路】还是得有的。我这边总结的几个点就是：
第一，不要出大问题；
第二，万一出大问题了，能快速止损或者有补偿的工具。
不然就只能干瞪眼，等着IT的一把手，被其他部门的人，狠狠的挑战一波。
你代码可以写的乱一些，扩展性不好，关系都不大的。如果你写了一堆自以为很漂亮的代码，就沾沾嘻嘻，而系统出问题后，又手忙脚乱，毫无办法。那你还不如不写呢?
展开
3
11
前段时间，刚转正，简单回顾一下。
第一，it团队早期，更为重要的快速交付【对业务有用】的功能，比如能提效的，能降低成本的等。至于代码写的优雅不优雅，不是最重要的，只要有办法尽量让核心功能稳定就行，或者说，出事了能快速止损。如果你说，我很有技术情怀，想憋大招出个看起来完美的东西，那就悲催了，因为it团队估计可能因为产出问题，被端掉。尤其在传统公司里。
第二，得有基础快速框架，里面会封装一些常用的工具和组件和基础规范。方便大家一致的快速的开发。
第三，至少得招一个厉害的帮手，能承担关键的复杂任务，能有效的帮你分担一些任务和压力。
目前技术团队已陆续交付了几个核心功能，业务方当前的反馈还行，继续加油吧。
第一，it团队早期，更为重要的快速交付【对业务有用】的功能，比如能提效的，能降低成本的等。至于代码写的优雅不优雅，不是最重要的，只要有办法尽量让核心功能稳定就行，或者说，出事了能快速止损。如果你说，我很有技术情怀，想憋大招出个看起来完美的东西，那就悲催了，因为it团队估计可能因为产出问题，被端掉。尤其在传统公司里。
第二，得有基础快速框架，里面会封装一些常用的工具和组件和基础规范。方便大家一致的快速的开发。
第三，至少得招一个厉害的帮手，能承担关键的复杂任务，能有效的帮你分担一些任务和压力。
目前技术团队已陆续交付了几个核心功能，业务方当前的反馈还行，继续加油吧。
展开
2
3
对于组建不久的技术团队，架构师就三个责任：
第一，效率，通过合理的服务划分，让大家各司其职。
第二，系统稳定性，这个是保命用的，系统不稳定，分分钟整个技术部门被端掉。
第三，挑最难的任务，并完成它。
第一，效率，通过合理的服务划分，让大家各司其职。
第二，系统稳定性，这个是保命用的，系统不稳定，分分钟整个技术部门被端掉。
第三，挑最难的任务，并完成它。
评论
1