作者: Richie.Liu
http://riccc.cnblogs.com
转载请注明原作者名以及文章出处
架构的核心
素描总是先草草几笔画出一个轮廓，修改到满意之后，再进行细节加工。人们看到博物馆里庞大的恐龙化石，虽然无法精确到眼神皮肤，但大体的形状已经跃然脑海中。
架构也是这样，但有太多的因素，导致系统构想非常美好，而细节却让人不见天日。在一个新系统开发之初，充斥在架构师眼前的，是漫天的需求、要求、期望，各种各样可选用的技术、设计实现方案。架构师需要用独到的眼光对待这些繁杂的细节，从特定的高度把架构的核心轮廓抽出来。
把架构的核心框架提取出来，架构师专注于核心框架的设计、验证，基于灵活、健壮的核心开发出来的系统才会强大。
数据处理型系统，架构的核心是数据流、伴随着数据流的核心处理模型（也就是业务流程、业务模型）。
例如ERP、MES、SCM等系统，整体上看，数据流最终会形成大大小小的环形，交织在一起，互相影响。如果没有一个整体清晰的模型，肯定会错误百出。就算在一个成熟的系统上，有时候觉得在某一环节，某种类型的单据比较独立，以为对它做一些特定处理，可以很方便的满足某个客户需求，但事后也许发现，这个处理给整体带来隐患，甚至是客户无法接受的。
企业应用架构中的数据流、核心处理模型，需要考虑如何映射、实现各种各样的管理模式、理论。例如MRP的make-to-order、make-to-stock，采购的normal PO/blank PO、JIT、VMI，以及各种程度的混合形式。
系统复杂时，核心模型由各个子系统、子模块的模型组成一个层级结构。
优秀的模型，不仅对产品架构、开发有重大意义，也能够快速的帮助客户分析管理上的不足、业务处理上的漏洞、不合理需求的悖论等。
有一点很重要，很多人认为数据处理型系统各个模块的基础数据是辅助性、不重要的。当然，如何将这些数据维护到系统中，对核心模型不重要，但这些数据的结构，一般都根据核心模型来确定。在核心模型细化、定案之前，是不能确定这些数据结构的，否则就出现这些数据结构不是服务于核心模型，而是核心模型到处迁就它们的情况。BatchML、B2MML已经把很多模型标准化，例如Equipment Hierarchy里提到的Enterprise->Site->Area->Process Cell->Unit，现实中Company、Plant、Storage Location、Purchase Group等如何映射到这个模型中，各种数据流、操作处理、业务管理模式如何在这个模型中进行？作为这类系统的架构师，需要彻底理解这些模型，而不是迁就的运用。
技术型系统，架构的核心往往是一个最关键的处理流，常常是某几种技术的组合使用，或者是某种设计思想的运用。
比如说Eclipse的出现而热起来的插件式，在SharpDevelop、MonoDevelop中都有运用。OSGI的核心是如何对插件的整个生命周期进行各方面的管理，安装、加载、提供/请求服务、释放、卸载等，也包括了Service的权限控制、Context定义等，在这些IDE类的产品中，自然的以Command等模式+插件式内核，实现IDE的框架，这就是最核心的东西了。如果Context、Chain of Responsibility解决的比较好，像代码编辑器、对象浏览窗口、Solution浏览窗口、编译调试命令等，整个系统用户可见的功能基本都可以看作是挂靠在内核上运行的插件，这样一来，架构的核心与整个系统功能相比较，就再清晰不过了。Eclipse在这方面运用的非常成功，所以灵活、强大，成为Java社区具有统治地位的IDE。如果SharpDevelop、MonoDevelop的架构能够做到跟Eclipse一样，我想大家可能会忘记Visual Studio的存在。
在写CMS的时候，看过现在的DNN，惊讶的发现它也把插件式思想运用起来了，而我之前一直在使用传统的模板+标签替换的方式思考。打破传统模式，运用新的设计思想，是很有成就感的挑战。尽管基于项目周期的原因，我最终选择的主要还是模板+标签替换，但也从它那里受到了一些启发，以后有机会改成插件式也不会跟现在的主架构发生冲突。
迭代中架构
一个系统，总会有很多功能是辅助性的，典型的一些是为了提高系统可操作性、分析提示预警等能力，降低操作员工作量等各方面的考虑，而设计的一些功能。这
些辅助性功能可能有一组一组的操作界面或流程，也可能是参杂在主流程中的一些细微操作；可能会衍生出很多附加数据结构，也可能只是为主数据结构添
加一些可调整性参数，或者只是从不同的视角去呈现、维护某些主数据结构。
大部分时候，把这些辅助性功能剥离开，才能够清晰地提取架构的核心。回过头来，核心架构必须接受整个系统需求的验证。
在提取架构核心的过程中，被剥离出去的功能粒度，完全取决于架构师的认识和把握，但是整个架构必须是可测试的，我们需要在迭代的过程中不断的把系统功能特性考虑进来，测试验证架构，完善架构。
数据处理型系统的架构测试，分为多种情况。目前想到的这类系统的模型，大概有两种，一是数据模型，例如上面提到过的Equipment Hierarchy等，一种是处理运算型的模型，例如MRP算法等。针对数据模型的测试，是模拟各种业务场景，包括管理方式、生产运作模式、不同的组织结构下的运作模式等等；针对处理运算型模型的测试，是设计各种场景的初始数据，验证结果的正确性、可行性，模型、流程是否存在漏洞、冲突等。可以想象，在这类系统的开发中，运用领域驱动思想是多么的适合。
技术型系统的架构测试，基本类似Unit Test。不管是运用某些技术的组合，还是某种设计思想，把核心架构用简单的代码表现出来，基于Unit Test对架构进行迭代，遍历系统的Use Case场景，是非常必要的。因为这类系统的失败，基本都是技术或设计思想没有掌握透彻，或者是错误的选择，基于Unit Test对架构进行测试，可以及早的发现和规避这些风险。
使用测试驱动的方法提取系统架构的核心，也是一种有效的手段。逐步、充分的迭代，总是会发现不足，使事物完美。
精细设计 vs 过度设计
精细设计与过度设计之间没有明显的分界线，有时候甚至已经接近极端倾向，还是会有很多人用赞赏、崇拜的眼光看待。
这是因为对技术溺爱的天性造成，对待那些高深的技术、设计思想，就像猎犬对待猎物，一旦嗅察到，一定要穷追猛打，直到品尝美味。这种态度一方面容易造成过度设计，更重要的方面是很容易让人陷入细节的泥潭，无法自拔，以及忽略领域知识的作用等，这也是现实中很多领导不放心完全放权给架构师的重要原因。作为架构师，固然需要对技术具有深刻的理解和认识，也需要具备架构师的眼光，从全局、整体的角度看问题。
如果能够比较顺利的抓住架构核心，一般不会在精细设计与过度设计之间徘徊。
个人经验觉得，一切以当前系统业务为主，以架构核心为主，去衡量精细设计与过度设计。
如果某个复杂设计在当前系统里面可有可无，那就把它去掉。不要在核心架构之外为系统做太多可能这样、可能那样的假设，为了太多根本不可能发生的假设，而把系统实现变得异常复杂，丧失系统的清晰度和可维护性，得不偿失。良好的系统架构，在架构层面已经保证了足够的扩展性；对于局部而言，也应当能够在已有架构之下，因应业务发展的要求而做进一步精细化设计。
有另外一种情况，就是团队成员的成长，总是需要有实践的机会，要经受挫折的磨炼，温室里面长出的花朵生命力总是脆弱的。对于架构师，在局部提供让人发挥的空间有一定的必要，这种情况下，架构师对核心架构的把握，作用就更为重要。