获得徽章 9
有了AI后，阅读文章的效率提高了好多，有时候想偷个懒，不确定某篇技术文章，【是否值得读】，那就扔给AI，提取关键内容，它会用大纲或者脑图展现，同时基于这篇文章，向AI提问。
评论
点赞
用一整大块时间来阅读这种方式，已经完全不合适我了。
用零碎的时间阅读是更合适的方式，高效专注又不累，最关键的是，能认真的读下去。
尤其是哪些一下子消化不了的知识，用零碎时间读，效果更佳。
用零碎的时间阅读是更合适的方式，高效专注又不累，最关键的是，能认真的读下去。
尤其是哪些一下子消化不了的知识，用零碎时间读，效果更佳。
评论
点赞
大家平时工作时，可以多利用一下一些文本软件的【宏】的功能，通过录制【宏】可以极大的提高操作效率。
比如说，我们经常要查询数据库，会使用sql钟的in语法，()里会放入一堆按照逗号分隔的订单号。这个时候，你可以利用像notapad++等文本软件，录制一个宏，然后配置好快捷键，一按下快捷键，多行的订单号就会合并成一行，并且以逗号分隔开。比如说订单号原本是多行的：
D0000000001
D00000000002
一按下快捷键后，瞬间就变成了：
'D0000000001','D00000000002'
虽然是一些小技巧，但是对于后端开发来说，由于经常要使用，无形中也提升了不少的操作效率。
比如说，我们经常要查询数据库，会使用sql钟的in语法，()里会放入一堆按照逗号分隔的订单号。这个时候，你可以利用像notapad++等文本软件，录制一个宏，然后配置好快捷键，一按下快捷键，多行的订单号就会合并成一行，并且以逗号分隔开。比如说订单号原本是多行的：
D0000000001
D00000000002
一按下快捷键后，瞬间就变成了：
'D0000000001','D00000000002'
虽然是一些小技巧，但是对于后端开发来说，由于经常要使用，无形中也提升了不少的操作效率。
展开
3
2
【领域服务要起名为xxxDomainService】吗?
我目前个人的想法是，推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler，xxxxBuilder等，这种就不太好立刻识别到，它们是某个聚合的领域服务，感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里，这样会导致它太庞大了。当业务逻辑开始复杂后，你可以在领域层里写一些辅助类，帮忙分摊一些领域逻辑，比如xxxHelper,xxxHandler。共同完成领域逻辑，但是对外的话，就是一个xxxDomainService。
【2】，随着业务需求的不断变化，在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService，你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
我目前个人的想法是，推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler，xxxxBuilder等，这种就不太好立刻识别到，它们是某个聚合的领域服务，感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里，这样会导致它太庞大了。当业务逻辑开始复杂后，你可以在领域层里写一些辅助类，帮忙分摊一些领域逻辑，比如xxxHelper,xxxHandler。共同完成领域逻辑，但是对外的话，就是一个xxxDomainService。
【2】，随着业务需求的不断变化，在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService，你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
展开
6
1
在我自己的开发团队里，我是这么定义垃圾代码的:
【第一，写的代码不在同一种抽象层次里。】
这句话是什么意思呢?比如说，你在DDD的应用层里的某个方法里，比如是下单接口。你做了前端入参的参数校验，这是不行的，这个应该是controller应该做的事情，再比如，你在应用层里，写一些复杂的计算，这些原本应该是领域服务里要做的。
DDD中的应用层是调度和协调的，不应该放以上那些逻辑，这会让人阅读代码的人，觉得你在乱写，很随意的乱写。
【第二，一个方法里代码写的太长了。】
别人阅读你代码的时候，其实不想立刻陷入到细节里的，他是想先知道大概的业务流程，觉得有必要的才深入去看。你一下子就把一坨代码扔出去给别人看，也是不对的。阅读代码的人想看到的是类似下面的结构：
input();
process();
output();
封装成小方法，并体现业务流程，同时确保看起来在同一个抽象层次里。
【第三，只满足刚好能用能跑就以为ok了。】
这个是非常致命的，代码写的又长又乱，还美其名曰，功能没问题呀。那我只能说，你是个没任何技术追求和随意的人，那基本上也就跟成长绝缘了。
你这么做，会让同组的人看不起的，觉得你一点都不专业，写的代码除了维护性差，浪费资源外，没任何好处。基本每写一个功能，都后面维护的人来说，都是灾难。
在周围都是高手的团队里，你是很容易被淘汰的。
【第一，写的代码不在同一种抽象层次里。】
这句话是什么意思呢?比如说，你在DDD的应用层里的某个方法里，比如是下单接口。你做了前端入参的参数校验，这是不行的，这个应该是controller应该做的事情，再比如，你在应用层里，写一些复杂的计算，这些原本应该是领域服务里要做的。
DDD中的应用层是调度和协调的，不应该放以上那些逻辑，这会让人阅读代码的人，觉得你在乱写，很随意的乱写。
【第二，一个方法里代码写的太长了。】
别人阅读你代码的时候，其实不想立刻陷入到细节里的，他是想先知道大概的业务流程，觉得有必要的才深入去看。你一下子就把一坨代码扔出去给别人看，也是不对的。阅读代码的人想看到的是类似下面的结构：
input();
process();
output();
封装成小方法，并体现业务流程，同时确保看起来在同一个抽象层次里。
【第三，只满足刚好能用能跑就以为ok了。】
这个是非常致命的，代码写的又长又乱，还美其名曰，功能没问题呀。那我只能说，你是个没任何技术追求和随意的人，那基本上也就跟成长绝缘了。
你这么做，会让同组的人看不起的，觉得你一点都不专业，写的代码除了维护性差，浪费资源外，没任何好处。基本每写一个功能，都后面维护的人来说，都是灾难。
在周围都是高手的团队里，你是很容易被淘汰的。
展开
32
12
如果你做过的需求多了，慢慢就会一种意识。需求里总有一些稳定的部分，比较少改。对于稳定的部分，在代码实现这块，就需要下沉，并保护起来。
而对于经常变化的部分，你要么用配置的方式，要么在代码设计时，通过一些合理的代码组织(比如用一点设计模式)等，让它易改易扩展。
一点小心得哈。
而对于经常变化的部分，你要么用配置的方式，要么在代码设计时，通过一些合理的代码组织(比如用一点设计模式)等，让它易改易扩展。
一点小心得哈。
展开
评论
1
【如果你网络上找关于DDD的文章，里面总会提到，领域服务不是必须的。】
这个我是持否定观点的，我觉得领域服务是必须的。虽然你的聚合根（实体的一种）写了很多业务逻辑，但是你总得暴露出接口给应用层去调用，这个时候就需要使用领域服务，封装好后暴露出去的。
直接让应用层去调用聚合根的方法，团队的人超级不习惯的，总觉得非常怪。且他们也认为破坏了分层。
目前团队的所有使用DDD的项目，都是有领域服务的。
这个我是持否定观点的，我觉得领域服务是必须的。虽然你的聚合根（实体的一种）写了很多业务逻辑，但是你总得暴露出接口给应用层去调用，这个时候就需要使用领域服务，封装好后暴露出去的。
直接让应用层去调用聚合根的方法，团队的人超级不习惯的，总觉得非常怪。且他们也认为破坏了分层。
目前团队的所有使用DDD的项目，都是有领域服务的。
展开
评论
点赞
在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