架构对话

近来用户现场经验丰富的gavin变的沉默少言，满眼血丝确闪闪发亮了。外地出差的roger在skype上正大笑他晚上养饱了眼，要保重身体。gavin插话说要休息几天，roger把话题也转到工作上来了。

gavin：以前做的几个小项目用着都挺好，现在又加进来的项目感觉功能上重复的不少，想做个平台，集成以前的应用，又能扩展，没想到想着容易做起难，现在一团烂麻，看着deadline就到了。

roger：那你开始时是怎么考虑的呢？

gavin：就是分层呗，有序依赖，应用层、业务逻辑层、数据层。

roger：那现在还是这样吗？

gavin：现在回想好像是犯了锤子和钉子的荒唐事，具体实际需求关注不够，走偏了。到最后模块间调用混乱，API冗余，遗留的C++库与驱动dll和C#之间相互调用，调试排错成了主要工作了。

roger：嗯，三层架构是很经典的老传统，加上著名的框架都是为了解决问题，对啊办法不是问题，你的灯红了啊。

gavin：少废话，帮我点点眼药水，亮绿灯吧。

roger：一般说来，这个系统的3种用户关注点或就说需求是出发点。你看下表

需求矩阵

用户	功能需求	质量需求	公司约束
仪修工程师	诊断故障	易用/扩展/可靠	维修手册
质检员	验证仪器	扩展/易用/并行	质检工艺规范
测井工程师	测量井使用仪器串	可靠/扩展/维护	仪器技术指标
解释工程师	分析测量数据	伸缩/易用/兼容	仪器技术指标

开发部的批准的技术规范和开发工程师都是内部约束。

所有人交流和关注点都是仪器，测井和解释工程师关注的仪器串也是仪器。

gavin：嗯，组合模式，我懂。

roger：架构有其自身特有的模式，不是这次的重点。你看这4种用户关注的都是仪器，可是语境或者领域是不同的，相应的是检验标准表、服务表、井区数据库，所以解码、刻度、展示这些横切的功能都在不同的语境角色下又有差别。而且系统有回放、重刻度和测井中重配置这些细分流程。你这个奶爸上有老下有小，同时处在几个身份下，被别人用不同的名字来称呼。

gavin：仪器在概念上要保持完整，其不同的模式也是可以被动态导入和改变的。这是不是按仪器垂直分层了呢？

roger：不管怎样分，都要保证独立性，就是bob大叔说的好架构

gavin：那这么多仪器又兼顾了这么多模式，会不会造成功能重复，配置信息重复？

roger：可以重构到工具类和设计关系数据库模型，今后工作的重点就放在仪器上了，独立后的平台稳定性和可靠性就有保障了。当让这个还要看需求对架构的演进了。

gavin：那技术上怎么保证实时性和可靠性呢？

roger：zeroMQ可以试试，数据保证顺序添加，通过并行来实现吧。仪器插件选用脚本语言作为一个代理来执行。

gavin：那下来我考虑考虑仪器的设计吧，把逻辑集中在仪器本身吧，我晚上再好好想一想，你这眼药水疗效听起来还不错哦？

roger：谁用谁知道。