商业软件的最大问题之一是技术架构比领域模型获得的提升会更多。
大多数领域模型都是普通的，并且可以由学校学生以比通常花费很少的成本来实现；然而，通常支持模型的软件架构，通常是过度设计的。一个常见的吹嘘是这样的：“该架构每秒可以处理 10,000,000 多条消息！” 但架构师无法证明这一点。
企业为它需要的东西付费，但得到它需要的东西以外的一切。因为传统的程序员在发现架构模式和实现方面会获得更具挑战性和满足感。而且这种架构模式往往是通用的，几乎可以用于每个项目，多次实施相同的机制后，光彩就会消失，并寻求新机制的更大挑战，而企业所需要的东西仍然太少。
似乎需要更好的管理或架构治理来防止此类涉足模糊的非功能性需求、结构、组件和技术。还有一种方法：可以使跨软件系统的领域模型比通用架构更具挑战性和吸引力。
使领域模型变得有趣，不仅仅如此，而实是引人入胜，可以探索：挑战团队通过实验和基于发现的学习来追求业务创新。失败的实验并不是彻底的失败，因为学习的目的是通向成功。将您的业务专家和开发人员团队视为在“知识领域”（即他们的领域）内推动创新。
使用领域模型进行创新需要业务专家和开发人员共同探索和发现独一无二的核心竞争力。
这种努力的必要条件是多次问几个问题。这是可以使用的第一组问题，没有特定的顺序：
- 为什么？
- 总是？
- 为什么不？
- 你确定吗？
- 立即地？
这迫使业务专家和开发人员不仅要达成共识，还要发现新的和更高级的理解。
在这一点上，模型可能反映了普通情况，或者可能更好一点，尽管它可能看起来比以前项目中的贫血模型好得多。毫无疑问，你仍然没有学到足够的知识。结果可能充其量反映了解决已知已知问题和围绕先前已知未知问题的清晰度。所以可能还有相当多的未知数，不管你认不认识。
要进一步考虑这些问题。用户可能会遇到他们不会报告的问题，因为他们无法想象更好的事情。为了首先防止这些情况，团队必须挑战他们的知识并拒绝接受平凡。以下是发现极端案例的第二组问题：
- 如果我们再往前走一两步，我们会学到什么？
- 根据当前模型，这里可能会出现什么问题？
- 用户是否会陷入难以恢复的问题？
- 该模型能否通过使解决方案显而易见来提供帮助？
通常，发现极端案例揭示了以以前未识别的方式使软件更加优越的机会。即便如此，您也可能会错过一些突破性的见解。那时，您必须采访一系列用户，以找出他们难以做到的事情。观察也可以教会你很多东西。如果您看到软件以意想不到的方式使用，它几乎肯定会大声疾呼缺少工作流程和更广泛的业务流程。请注意这些并将它们作为首要任务解决。
不要从“错误”的决定中“预测”用户，因为他们当前的决定可能是正确的事件，尽管较早的决定现在发生冲突。有一个业务流程潜伏着。此类情况必须通过深度学习来想象或检测、探索、试验并不断重新发现。当获得足够的知识来理解问题和解决方案时，一定要展示一系列数据和一系列选项，以帮助用户快速达成明智的解决方案。