件开发的一个迭代周期中的四个工作流：
A-业务建模——定位需要改进的目标组织（人群或机构）以及该组织接下来最需要改进的问题。
B-需求——描述为了改进组织的问题，所引入的信息系统必须具有的整体表现。
C-分析——提炼为了满足功能需求，所引入的信息系统需要封装的核心域机制。
D-设计——考虑质量需求和设计约束，将核心域机制映射到选定非核心域上实现。
很多开发人员只有D的知识，当岗位发生变化，需要他做A、B、C的工作时，按道理应该去认真学习A、B、C的技能才对。
但是，很多人并不愿意走出自己的舒适区，甚至还会有意无意地把其他人拉到自己的舒适区。
（1）在和涉众讨论需求时，频频蹦出一些“技术潮词”，目的就是以自己的“所长”来碾压涉众，从而掩盖自己业务建模和需求技能的不足。
（2）在讨论核心域的类模型时，动不动就谈到如何实现或者质疑“会不会有性能问题”，从而掩盖自己抽象能力的不足。
以上是之前批评过的。
下面再加一种：
（3）为了掩盖自己的无知，在不好好学习相关建模技能的情况下去做需求、分析相关的工作时，喜欢在各种用词前面加上“业务”、“用户”等词汇，显得咱搞“技术”的大爷多么亲民啊，都低下头来和你谈业务、谈用户了！
例如，有的DDD文章也使用用例的概念，却是“不学有术”，言则称“业务用例”，作者可能觉得：我在说用例时没有谈到“技术”嘛，所以用例自然就是“业务”的了！感兴趣的读者可以自行搜索关键词：DDD "业务用例"。
类似的还有，在“需求”前面加“业务”，变成“业务需求”，加上“用户”，变成“用户需求”，以表示自己对业务、用户的重视。
最近几年，领域驱动设计被胡乱吹捧，所以，流行的前置词又多了一个“领域”。
知乎上的这篇阅读量还比较大的DDD文章，先不说“领域模型……反映需求的本质”是错误的，就看这个累计叠加了三个前置词的“领域内用户业务需求的本质”就叹为观止了。
编辑搜图
大家可以观察造词圈子产出的各种文章，看看有没有我说的现象。
