知道想要做什么，可是找不到头绪。
不是那么清楚想做，有一个模糊的印象。大体是软件方面组织好了，自身价值增长，应该有足够的信心去找一些工作，或者发现一些生活中的事情。
现在对软件的思考达到了一个程度，带动的有对企业或者游戏的思考，还有自己那个项目，设计相关。
我想能抓住软件的整体，那些对象和连接能很好地组成一个项目的运转，我并没有找到一个很好的思路来编织。当然对软件需求的理解需要从实际项目中得到一些经验，我没有实际项目经验。可是觉得并不到那一步还，在那步之前，也可以理清一些软件的建造。
就像凸出的竹笋顶不动一层障碍。基本平台已经知道了，站在这个平台上确实可以看到一个立体的世界。可这并不是解决问题的方向，不是为了搭平台，是为了建软件，平台只是一个理解角度，或许并不去用还，只是站在上边看问题多了一个角度。
从软件本身看又显得混乱，平台可以用来辅助搭建。
软件是一个从上倒下的阶层式，基本代码被编译成易用代码，组成每一个对象，对象集合成服务，服务间相互运作，上游有个顶层控制室吧，对服务进行调整、协调。
一个需求进来，想要通过各种服务的协调来完成。整个项目需求都在，每个需求业务进行分类整合。每一个业务都有大大小小的模块，显得很零碎，从最大逻辑到细节处理，像是各种球在空间中大小不一地连接在一起。这在创建的时候抓住主球，其它的给细节部分做。每个主球之间的交互走通。
在需求方面是这样的，到实现空间里。
需求是层表面，实现的时候每个业务有逻辑和数据组成，每个“球”就涉及到了存储。当需要进行固态存储的时候，根据传统MVC分层就有些打破原来的球体。如果舍弃原来的分层，操作从。。统一端口进来，立体上只能根据这个端口的大小，围绕着它铺展开链接和球体。从业务考虑，每个业务都要从端口中分一些流量，处理好了之后再从端口中送出去。有时需要用到提取数据，和数据空间连接只需要占用内存。写到不同的DB里，使用不同的SessionFactory。一个程序有好几个数据库链接工厂，建立工厂要占内存，这比起工厂里边的链接来，应该不算什么。
也就是可以忽略MVC的角度，只有 “通道” 和 “处理球” 。再有就是处理球之间的链接，回到了业务表面层看问题。
现在又是球体和链接的协调，最基本的，走清晰的路线就可以去实现。
一个软件有一些基本的协作对象，这些大对象包囊了很多小对象和链接，像是一个整体块，或者提供展示，或者是用户的角色包装，或者提供模块服务。
这样，软件大体拆成了模块处理，模块的建立和模块间的链接。
至于其它的东西。。。