坦克模型大规模项目应用
在大规模项目应用
我们前面说的所谓的“常规项目”是指从头开始开发一个新的项目，基本上是遵循的从上到下的项目研发模式。但是，经过若干年的信息化，每个企业都已经或多或少的拥有了自己的信息系统了，推翻了重新开发是行不通的。
我个人认为，领域驱动设计之所以会如此获得很多人的青睐，跟它最初将自己的应用场景放到了企业架构层面不无道理。
企业中的组织机构中有多种组织编制关系，每种组织关系中会有不同的汇报和隶属关系。有的组织机构同时具备水平管理或者垂直管理，如此，这样的组织架构所执行的业务的含义也会有很大的不同。
企业架构中的应用架构视图，告诉你有多少遗留的系统，每个系统着力于去解决在企业管理中的某个层面中的业务问题。
企业架构中的开发架构视图，坦克模型告诉你有多少个开发团队和维护团队在现有的或者将来的系统上工作着，那么这些团队之间都是什么样的关系呢？他们应该如何协助才是合理的？
在大规模项目中，为了要保证信息化建设的延续性，保护已有的投资，就要在系统建设开始之前，进行大规模的领域走查，在分类时要确定更大规模的信息架构用于跟企业架构对应。常用的方法有:
1.精炼:一个项目足够大时，不是所有的子系统都具有一致的优先级，我们应该对核心业务和支撑类业务进行区分，对核心领域和通用的子领域进行区分，对要优化或者要删除的领域部分进行区分。
2.职责分层: 因为组织机构是分层的，所有业务组件和领域模型也是分层。不同的层级关注的点不同，这点需要尤其注意。
3. 上下文映射:当拥有不同的研发团队、遗留系统时，就会自然的形成若干的限界上下文，有的领域概念在不同的上下文中含义不同，例如:一个客户，在同一个系统的呼叫中心上下文中是访销客户，在CRM上下文中是零售终端，在物流上下文中是配送客户，在专卖上下文中是被监管的客户。要在一个模型中维护所有的信息是不太现实的，应该在各个上下文中建立起概念间的映射关系。
4.强化（highlighted）:如果这个系统足够大，大到让所有的人一看那些细节就晕，那么就应该在其系统远景的基础上，整理出一幅能够轻松让团队每一个成员都能达成共识的强化领域模型。在超大规模项目中使用这样的模型，会让团队的领域整体把握能力大大增强。
真实案例应用
我想最后还是可以哪出我们最近的一个“全面预算管理”系统的例子来跟大家分享。这个系统是一个非常大规模的系统。要在集团公司和旗下的若干个子公司中部署实施，每个子公司要在集团统一的预算体系下有自己的特色（这是中国的企业最希望强调的一点），预算的过程要从上而下然后从下而上的反复过若干次，并且各责任中心的预算的版本要有保留。
最后，坦克模型根据预算的实际执行结果要跟预算额进行比对分析，以便为考核以及下一个预算周期的预算打好基础。无论是预算体系的设计还是预算的编制或者变更，都涉及了诸多的业务部门参与，另外研发团队分成若干个部分，还有要和若干的遗留的业务系统以及财务系统、考核系统对接。
在接收这样的大项目时，我们的第一步是要做企业架构的采集和评估，了解集团企业的战略目标，明确系统建设的长期目标和短期任务。比如：如果企业“全面预算” 的长期建设目标是提高企业的“预算精准程度”，那么它希望通过几年的建设达到该目标；那么企业“全面预算”在年内的短期目标是实现预算编制和修订工作的电子化吗？
坦克模型针对确定下来目标，进行领域走查，确定热点的业务组件。我们会根据其组织架构将业务组件和领域模型进行职责分层：
1.决策层 全面预算体系的设计。
2.执行层 全面预算工作的编制和修订。
3.控制层 全面预算编制的评审和执行结果评估。
如果第一年的建设目的是实现编制和修订工作的电子化，那么决策层的工作一定要做，但不应该将它作为一期软件实现的重点。我们可以采用批量导入的方式来建立企业的全面预算体系。
为了更大程度的保护既有投资，坦克模型我们需要考虑“全面预算管理”系统和其他系统之间的业务流和信息流向：哪些信息流是要求同步的，哪些可以是异步的。为了保证各研发团队不发生集成大爆炸，各限界上下文之间的集成部分要提前考虑，并建立定期的沟通交流机制。
领 域驱动设计不光给我们带来了理解企业信息化本质的最实用的思考方式，还给我们带了切实可行的实现模型。在IBM SOA的解决方案中，“领域驱动设计”被其推荐为提炼和实现SOA服务的参考方法。我们在众多的大规模项目中成功的应用了这一敏捷方法学，愿与更多的朋友一道在项目中积累自己的使用心得。
相关信息：