漫步是个好名字的个人主页 - 动态

系统分析设计方法论爱好者

·

突然的思考，AI时代，程序员应该保留什么能力？

AI编程确实很强大，只要描述清楚，它就能生成复合要求的代码，甚至是项目，而且比人做的还要好。

程序员的意义呢？思考企业中的项目，往往经历了几波开发人员，即使不是屎山，也是充斥着补丁，代码意图早已不是最初那么清晰，存在各种矛盾，试问这样的代码，AI编程工具能帮上忙吗？能帮多少？

所以企业中的项目，难点在于“只要描述清楚业务”这件事上。

这样的项目缺乏有经验的程序员，它能够梳理业务，统一业务模型，简化业务，并最终通过AI重构或者实现。

这里也想到产品经理，并不是所有产品经理都能理清业务，他们经常是如实描述需求。用户提了八种场景，他就会记录八种场景，殊不知，可能就是三个维度的组合。

所以，我觉得，程序员应该具备理清业务，化繁为简的能力，这是最重要的，其次是驾驭各种AI工具的能力。

展开

服务端与架构

系统分析设计方法论爱好者

·

2月前

MCP 解决“单个 Agent 怎么调一个工具”
A2A 解决“多个 Agent 之间怎么商量”

• 单 Agent：一台电视，自己会思考，但缺“外部手”——用 MCP。
• 多 Agent：家里一堆会思考的电器，需要“商量”——用 A2A。

展开

大模型生态圈

赞过

1

系统分析设计方法论爱好者

·

3月前

面对一项工作，需要看透其本质。如何看清本质？需要的是方法论。DDD是方法论，RUP也是。即使有了方法论，也要结合实际情况，做各种取舍。想要做好项目，技术，业务，方法论，缺一不可。

服务端与架构

赞过

1

系统分析设计方法论爱好者

·

4月前

作为一名后端开发人员，开发了很多业务软件，无非是用一个三层架构差不多的架构，写一个数据访问层，通常就是实体和mapper ；写一个服务层，一个纯纯的用着面向对象语言写的一对面向过程的业务逻辑；以及一个表现层，通常是一个mvc 。通常我们还看了很多面向对象设计的书籍，什么封装、继承、多态、接口、抽象类、设计模式等。困扰我很久的问题就是
1 为何要分这些模块而不是那些，有无系统的推导依据？
2 学了那么多面向对象设计，如设计模式，真正又用到了几个？

展开

服务端与架构

1

系统分析设计方法论爱好者

·

4月前

摘自thoughtwork 洞见领域驱动设计 - - 在DDD中，ApplicationService和DomainService是两个很不一样的概念，前者是必须有的DDD组件，而后者只是一种妥协的结果，因此程序中的DomainService应该越少越好。

质疑 - - 领域服务并非越少越好，而是按需存在。如果领域对象order.xx()不合适的时候，就应该将xx放在order的领域服务里。另外，order 不适合调用其他限界上下文，因为必然出现类似httpclient 得东西，这样，领域服务就依赖了具体实现，我觉得应该放在端口适配器里的out 部分。

展开

等人赞过

7

8

系统分析设计方法论爱好者

·

5月前

关于领域服务的约束

通过对领域服务命名，可以限制领域服务的行为。避免领域服务侵蚀聚合的职责。

领域服务通常用来解决某个专题业务，是放置各种行为类型设计模式的好地方。

#领域服务

展开

服务端与架构

系统分析设计方法论爱好者

·

5月前

讨论私有方法该不该测试的问题 1 如果私有方法不值得测试，就不存在这个问题了 2 如果值得测试，公开后会导致本该封装的内容外泄；不公开又无法测试，如何做？
 方法一，公开，并加入提示性注解，但依然有人不遵守，还可以使用架构工具验证是否违反该规则 方法二，单元测试代码与被测试方法在同一个包里，就不需要公开了
 我倾向于方法二，而且现在的单元测试就是这么用的。
 #单元测试 #私有方法 #每天一个知识点#

展开

关注了

系统分析设计方法论爱好者

·

7月前

我觉得掘金里应该有一个“腰突”的圈子，程序员的最高境界应该是没有腰突！

#挑战每日一条沸点#

系统分析设计方法论爱好者

·

10月前

领域驱动设计 = 方法论 + 词汇库。
方法论即构建领域模型的指导方法。
词汇库即方法论中使用的工具（构建过程中使用了很多名词，它们即工具）

领域驱动设计并不复杂，无需惧怕。因为它不要求您设计好一切才开始，只需心里种下这颗种子，模型会渐渐演进而来。

类比面向对象分析设计，只需了解设计原则，创建一个对象，将对象逐渐丰富起来，渐渐加入其他对象，思考他们之间的关系，引入合适的设计模式，一步一步，良好的面向对象程序就渐渐演进而来了。

#领域驱动#

展开

服务端与架构

等人赞过

9

4

系统分析设计方法论爱好者

·

10月前

#我的后端Java之旅# 软件开发之所以复杂，源于两个方面，一方面是问题领域本身复杂，另一方面是实现方案复杂。前者无法避免，后者可以控制。用例驱动是从外向内看，看到的是表象，领域驱动是由内向外看，看到的是本质，只有本质才能以不变应万变！

本质虽好，但看清本质需要功力，表象虽肤浅，但可以立即满足需求。

最后，看项目的目标是什么。如果仅仅是在预定时间点完成预定的功能，那用例驱动更优；如果要不停演进迭代，那领域驱动更优。

#ddd#

展开

我 & 掘金

赞过

2