因此，毫无疑问，构建领域模型是我认为当你作为团队来处理它时最好的事情。甚至让非技术人员和“业务”成员参与建模会议。当你把合适的人放在一个房间里并在白板上敲定东西时，可以快速完成很多事情。但是你没有那种奢侈的时候呢？当您必须单独构建复杂的域模型时怎么办？在过去的一个月左右，我一直在这样做，并做了以下事情：
虽然这些技术运作良好，但我不确定它们是否像真正的协作努力一样有效。我认为很容易被一个概念冲昏头脑，后来才意识到它违反了 x 或 y 要求。在隔离工作时，您使用了哪些技术来确保您的对象/域模型符合目标？
我认为每个人的做法都不一样，但是...
我几乎总是从类图（通常类似于 UML 并且在纸上）开始，特别注意类之间的关系及其数量。此阶段的验证主要是试图了解实体的高级语义是否一起有意义。
然后开始勾画关键功能，尤其是那些涉及协作的功能。确保协作中的对象可以通过关系相互联系。在这个阶段，我将使用绘图工具 (StarUML)。
然后是 gedanken 实验。我在脑海中遍历了我能想到的最棘手的用例，看看我是否可以设想一种方法来用给定的设计来解决它们。这不是伪代码，只是逐步完成每个主要任务/功能并按照图表的线条来确保我没有错过回调、循环依赖等。
我认为一个关键是在你对设计的任何特定方面感到满意之前，不要过于拘泥于设计的任何特定方面，它可能会工作得相当好。在我看来，如果您无法在心理上逐步完成设计以评估/验证它，那么您要么对问题缺乏了解，要么纸上的设计还不够完整……
然后，如果时间允许，把那个放在一边，看看你能不能想出一些真正不同的东西……
如果您自己构建它，请确保它具有适应性，因为您不可能在第一时间想到所有东西。
拿一些大纸。把所有的东西都画出来，弄得一团糟。不要担心让它变得完美。把你想到的所有东西都放下，划掉那些证明没用的东西。这篇论文看起来就像你的脑海里到处都是对象模型的碎片。当你想到已经写下来的东西时，让这些东西脱颖而出。在这个过程结束时，你会一团糟，但肯定会有很多好主意。在这一点上，我建议向人们展示这个，但既然你说这是不可能的，我们会继续前进。
现在坐在带有 UML 工具的计算机前，绘制出类似于大脑转储亮点的东西。考虑对象模型的主要部分，然后考虑使这些部分协同工作的更次要的东西。一旦你确定了一些东西，把那个 UML 变成代码，然后开始编写一些测试来看看它是否有效。冲洗并重复。