总觉得如果一个内容被深刻地理解了，那么当在他口中说出来的时候，应该是很简单才对。
所以一直觉得，编程里那些不容易理解的，需要记住很多内容的东西都是有缺陷的。自己又比较自我认可强，看不到别人的角度，表现上有些自我。自己想的只是，事情还有很多解决方法，为什么要被那一种很难学的方式占了路子，而且找不到理解透彻的，有点为这种状况气愤，觉得肯定是没有好好做的原因，或者是一些人太安于现状的原因，或者是一些找不到出路就说没出路的人，自己没吃透却站在高处误导别人，阻碍大部分人的进一步思考。
即使这样，自己该做的事情还是要继续做，去探索可以用来解决问题的架构。首先3D建模还是比较擅长的，玩了那么久的游戏，对场景想象比较容易。于是一个平面问题，可以用一个立体方式来解决，这样就多角度一些，把事情变得容易。
说是这样说，具体做的时候，到具体项目的时候还是暂时没有想出来。知道以前自己所提出的面向对象的架构是一种不是很确切的说法，需要更合适的描述。这样，没有成熟理论的话也不好去找工作，没有底气。
游戏的事情也一直徘徊着弄着，最近又来了一股隐藏的热情，不知道是否需要把这份继续。对有些人来说还是有帮助的，真可以实现的话，对自己也有很多帮助。
主要是不想总是碰电脑。不想总是盯着屏幕，生活中有一些很漂亮的景色，我的眼睛渐渐适应了屏幕光和它的刷新、它的尺寸范围。当看开阔的东西时候，眼睛有些睁不开。用手把光线来源遮挡到像屏幕那么大的时候，就可以正常看得很远。总觉得用电脑，和这些电打交道不是那么合适，高丰富的内容在周围环绕，不一定非要通过电脑，可以是一些比较传统的方式，画画之类，到电影院看电影。
至少现在可以做的事都和计算机有关。如果思想足够好的话，可以从中抽象出来，用到别的领域去解决 问题。别的领域...不知道可以做什么，现在这边还对软件架构比较有热情，不管是不是一时，是自己会经过的地方吧。
觉得电脑，还有相似的工具，与其它东西最大的区别是可以玩video game。独立出来一个独特的空间来体验剧情，不需要小说里看到一些事物的描绘还要去想到底是什么样子，这样都可以直接看到、听到。比起video game来，电脑对企业服务的应用就像是小儿科了，也就是说，按道理来说如果用运转好游戏的逻辑去处理一些企业软件编辑，应该很容易做到。不是“按道理”，就是某种感觉。因为游戏逻辑要比软件逻辑在电脑里走的深。体验游戏的过程，是踏实了一个电脑里边的世界，有种从内部开始向周围思考逻辑的感觉。
每个企业软件也应该有一个核心，从核心里看问题，每个固定服务都是个NPC，每个使用这个软件的人都是一个玩家。这样新的需求分三部分：给玩家的角色增加这份智能；从服务器世界多设置一个相关的NPC；给玩家设定一个对话这个NPC的路线。这样一边面向客户，一边面向服务，一边面向业务逻辑。
面向客户这边是前端和主语言实现；面向服务这边是主语言和数据库实现；面向业务逻辑这边是全部交给主语言处理。对应的分别有些像view，model，controller。这样V部分做的是把视图用主语言包起来，M部分是把数据库用主语言包起来，C部分就直接用主语言引领包好的两部分、牵引玩家到各个NPC所在点对话。还有一个就是真正的controller，之前那个C只是用来领路的，不如改成map好了，真正的C是可以更改玩家角色技能，可以建立新的路线，可以增加新的NPC的那个游戏控制室。
制造一个武器，先去买铁，再去打造师打造。后来要求高了，自制武器样式，要先去卖铁，再去铸模师，再拿着模子去打造。这个过程就是多了个铸模NPC，多了个用模子打铁的NPC，多了一个打铁移动路线。这样把问题立体化，还可以做很多事情，比如说各种NPC放在哪里，路线怎样设定，可是在不同的城市里，可以在楼上楼下，可以站在一起。这样变相解决高负载之类的问题。
和游戏不同的是，这个map，玩家进来后所走的路线是程序员给定的，不同的需求直接给设定好不同的路线。而不需要玩家自己走。也就是编好表面，编好底层，然后程序员自己在中间玩，觉得玩得不顺可以申请到上层控制台改一改地图，从新布置一下各个NPC的路线和场景地图。
这样一个软件里的部分有：角色，NPC，地图，代玩程序，游戏控制台。这五个内容相互协作，共同完成变动的软件需求。除了企业方增加软件需求以外，软件本身随着新需求加入后，时间的推移也在内部变动着，这种变动是不被企业直接看到的，可以影响到软件表现出来的效率。
于是一个新需求进来，首先是软件吞掉这个新需求，然后随着新需求的运行再慢慢消化开。对用户来说是从“吞掉需求”的时候就可以用了。这样内部不断调整，当再来新需求的时候又可以先吞再消化到合适的状态，这个软件就可以持续健康增长。
角色，NPC，地图，代玩程序，游戏控制台。这是一种新的建模方式，可以逻辑分成更形象的模块，给编程划分好更明确的职责区域。来新需求时各模块自身可以从整个软件中抽出来单独修改。现行的软件问题大概都可以通过模块之间的交互协调得到解决。
稍微想到的是，这个建模方式之所以能解决很多问题，是因为把问题映射到更广阔的解决空间。角色功能的“增加方式”，NPC的“选取雕琢”，地图的“布景”，代玩程序的“游戏路线”，游戏控制台的“调整”，都是可以用来铺展软件问题并加以解决，进一步把计算机问题映射到适合人脑思考的空间。
选取这种建模，架构起来职责分配就容易一些。在这里，角色是以前的view，npc是以前的model，地图和代玩程序协调组成以前的controller，游戏控制台像是原来软件架构。也就是把原来的控制层少部分逻辑合理的分离出来分给view和model（数据库连接/处理类），自身再裂变成map和代玩程序（director）两个模块，现行架构师站在游戏建造控制台对一些对软件的初建和成长进行角色（player）、NPC、map、director的调整。以这个模型在分配任务的时候网页设计手和程序员都比较容易理解自己的职责。分布式处理、高负载也很容易直观理解，把量大的数据访问分配给单独的NPC，调整下NPC在map上的位置让director容易跑。在建表的时候就以NPC角度考虑这个表/数据库的结构。在设置NPC功能的时候以游戏环境里NPC将被访问的量调整NPC的服务内容。即使都没有预设好，也可以在发现问题后各部分配合着进行灵活调整。
在最外围，有个外部架构师。负责这五个模块的任务分配、逻辑抽象。这和controller部位的架构师任务有些不同，controller属于内部架构师，考虑的是场景控制，NPC分合，玩家新功能增加，以及和director的协调、处理反馈，吞进新软件需求。内部架构师直接涉及到了内部逻辑包括页面、主语言、数据库，它们的相互协调和工作分配。而外部架构师只是负责这个模型的完善，引导和教会整个团队调整思维角度，负责初始架构。
每一个人都有自己考虑的范围。
