困惑—接下来的java路如何走？

做个自我介绍，本人2010年毕业（重庆邮电大学计算机专业），在工作的3年中，经历了一些事情，第一年在一个医疗软件企业的培训工作，主要负责新员工的oracle培训，但个人比较喜欢java，然后就毅然决定辞职，于是乎11年底辞职，12年2月到了上海并进入现在的公司，所以正式从事java开发也就1年多。介绍完了，比较啰嗦…

最近在做一个游戏项目，前段是IOS平台，后端使用java（springMVC+spring+mybatis），IOS和后台通过json交互，我只做后端。由于客户要求短时间内能上线运行，所以没有细致的做需求调研，只是简单的制定了一些接口供IOS调用，并编写了接口文档，采用在具体开发的时候进行迭代修改的开发方法。

先说说整个项目的运行环境：

         运行平台：lvs+keepalived集群

         Web容器：jetty7

关于运行平台和web容器在这里不想做详细的介绍，在以后的博客中可能会分享出来，毕竟本文主要是想谈谈自己的困惑，还希望有同样困惑的人或已经走出困惑的人一起分享自己的观点。

项目快要结束了，只是在添加一些新的或修改一些原有的逻辑和元数据，修改元数据还好，一到修改原有逻辑的时候就觉得很无力，且修改的地方还蛮多，没办法只能硬着头皮改。在意识到这些问题的时候，就慢慢的体会到似乎是架构上的一些问题，然后就看了一些DDD和设计模式的书，比如Eric的<领域驱动设计>、<大话设计模式>等书，然后试着对系统中的一些代码进行重构，比如将玩家购买物品逻辑抽象成模板，然后购买某种物品时就直接实现模板预留的方法等，的确如此，重构后的代码精简了许多。但还是觉得不够，查看了以前设计的实体类，都是贫血模型的设计，所有的接口方法都集中在service中（估计很多人都是这样做的），按照DDD的设计看，很多职责应该设置在具体的领域类里，从而避免将领域类的固有职责分配到service中，想要拆分，但又无从下手，因为包括我在内的很多人估计都分不清“对象职责”这个概念，迷茫了，接着找出路。

在看到<大话设计模式>时，其中的几个原则虽然很好理解，但结合当前游戏项目来看，还是很难做到的，比如“单一职责原则”，强调类或接口的职责单一，但像现在这种贫血模型的设计，所有的方法都在service中，领域类只是简单的DTO，拆分开来也没有任何意义。再比如“开闭原则”，强调对修改关闭，对扩展开放，而当前项目中修改的基本都是一些具体的方法逻辑（我将一些经常修改的逻辑封装为单独的方法），如何做到对修改关闭，对于扩展而言，基本上看不到有什么扩展，所以更无从下手，迷茫了，接着找出路。

还有很多迷茫…

以上结合当前项目的重构说了自己的一些困惑。我相信很多初学者也和我有一样的困惑，每每看到Jdon上banq以及其他人在架构设计上的探讨，自己都会发出感慨“还有多少路要走，才能到达这样的高度”，也会问自己“接下来的java路如何走？”。希望那些和我一样还没有找到路的童鞋一起探讨，那些已经找到路的师兄也说说自己的观点。

即便迷茫，也要努力找到出路，因为做开发不全是因为生存，还有自己对程序开发发自内心的喜爱..！