欢迎大家回到我的连载，从这一期开始，我们正式进入ICONIX的世界。闲话少说，进入正题。
　　什么是域建模呢？我们设计一个系统，总是希望它能解决一些问题，这些问题总是映射到现实问题和概念。很明显我们的系统依赖于这些问题，对这些问题进行归纳、分析的过程就是域建模（这个域，指的就是问题域）。
　　好了，讲理论大家要昏昏欲睡，我这个小小的连载也没办法把所有的概念说的一清二楚，要是有兴趣的话可以打电话跟我畅谈（前提是不许打手机），现在我来用一个实际的例子讲述域建模。
　　用个比较简单的例子吧，本来昨天我是想用HelloWorld来的，可是它实在太简单了，不能说明问题，考虑再三，我使用一个猜数游戏来说明问题。这个游戏相信学过编程语言的都应该很熟悉了：输入一个数，如果猜中了显示“你好棒啊”然后结束，如果不对，系统告诉你是太大还是太小，然后重新让你输入，直到猜中为止。
　　现在请拿一张白纸，我们开始归纳问题。
+--------------------------------------------+
|　　系统应该准备一个正确答案　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　玩家可以输入一个答案　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　系统应该比较玩家输入的答案和正确答案　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　系统应该显示玩家每次输入的结果　　　　　|
+--------------------------------------------+
　　遗憾我这个例子还是太过于简单，不过简单也有简单的好处，从这个简单的例子可以看出归纳问题的基本要点。
　　第一是不要涉及内部的流程，别出现“如果输入不正确，就怎么怎么样”的句子，这些并不是正确的问题，正确的问题必须明确的，清晰的，如果可能的话全部按照“什么可以干什么”的格式来写。
　　第二是不要一开始就进入细节（抱歉，我这个例子例外，它实在是太简单了），包涵太多细节的问题将会是一个长长的清单，这种清单根本没什么用。尽量从最高一层分析，但也不要简单到“用户可以玩游戏”这种笼统的问题。总之一个原则是全面、清晰、明确。要做好问题域分析完全取决于设计师的水平与能力，这就不是可以简单的看看书能达到的了。
　　好了，现在我们有了一个系统问题域的清单，可以进行下一步工作：发现类。
　　把问题清单中的名词都提出来，得到一个名词列表，这就是类的来源（不过不忙，这只是初步过程）
+----------------+
|　　系统　　　　|
|　　玩家　　　　|
|　　正确答案　　|
|　　答案　　　　|
|　　游戏结果　　|
+----------------+
　　不是所有的名词都能作为类的，接下来需要进行筛选。
　　玩家是参与者，应该放到用例图上去
　　系统太笼统，不能成为一个对象的名称
　　答案和正确答案容易混淆，但称为输入答案又容易被误解成一个动作，干脆叫做玩家答案
　　结果不明确，察看前面的需求，应该分解成错误信息和完成信息
　　筛选完毕后，得到下面一个名词列表：
+----------------+
|　　正确答案　　|
|　　玩家答案　　|
|　　错误信息　　|
|　　完成信息　　|
+----------------+
　　这个列表缺少了系统，显得太单薄，回过头再仔细察看需求，应该引入一个游戏引擎，由它来充当调度者。
+----------------+
|　　游戏引擎　　|
|　　正确答案　　|
|　　玩家答案　　|
|　　错误信息　　|
|　　完成信息　　|
+----------------+
　　同时修改前面的问题域，现在系统已经明确是一个游戏引擎。这种替换当然是一种理想情况，通常都会发生分解和关联，那时候需要扩充问题域，有时候还需要建立新的问题域。
+--------------------------------------------+
|　　游戏引擎应该准备一个正确答案　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　玩家可以输入一个答案　　　　　　　　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　游戏引擎应该比较玩家答案和正确答案　　　|
|　　　　　　　　　　　　　　　　　　　　　　|
|　　游戏引擎应该显示玩家每次输入的结果　　　|
+--------------------------------------------+
　　现在可以用Rose来制作Class Diagram了，同时可以用RAD工具来搞一个小小的GUI来看看效果，发现类工作到此告一段落。不过问题域分析还没完，类与类之间的关系还没有归纳，当然，那是下一段要讲的事情了。