在进行设计原则的讨论之前，首先要明确一个事实:
在一个软件项目团队中，在讨论项目设计的时候，每个人都会有自己的设计理念。这些设计理念一般都跟每个人的成长经历有关系。跟用户密切接触的人员，比如：产品经理，售前经理等，在设计一个系统的时候更考虑整个系统如何设计才能更加方便用户，更加贴合用户的业务流程，才能解决用户面临的问题。而研发体系的人员，比如：系统架构师，开发经理，一般更加侧重于系统架构如何高效运行，如何减少代码工作量，如何减少系统的复杂度。
因此在一个项目团队中，经常会出现这样一种情况：如果一个项目设计的决策权在产品经理时，在开发人员真正开发代码的时候，会抱怨产品经理设计的功能没法实现，或者实现的难度太大了，甚至对整个架构造成巨大的破坏。尤其是在项目后期增加需求的时候。
而如果一个系统完全由开发经理或者系统架构师来实现，可能会设计出一个非常方便开发人员使用的架构，但是在满足开发经理的各种需求的时候，因为架构的限制可能没法实现，这个时候产品经理或者售前经理又会说，这是什么破系统，什么都实现不了。
这个问题的核心原因在于：产品经理（售前）更加熟悉业务，不关系技术实现难度的问题，更多的是从业务角度来设计系统。而开发经理（架构师）更多的是从技术角度来设计系统。以模块化为例，对设计由一定经验的人员都知道，设计之初的模块化的划分至关重要。但是真正设计系统的时候，产品经理更多的是考虑用户业务模块的概念，而架构师在设计的时候更多考虑技术模块，代码复用等模块概念。
那如何才能设计出更加完善的系统架构呢？在设计系统架构的时候应该遵循什么原则呢？
我的意见是：所有的设计不能由某个人来决定是否合理，应该遵循一种大家认可的设计原则。评价设计是否合理应该从多个角度来进行评判，不能一直站在一个角度来评判设计的优缺点。比如不能站在业务架构的角度来批评技术架构设计的不合理。也不能站在技术架构的角度来批评业务架构不合理。应该让大家从两个方面都要有一定的妥协，兼容两个甚至多个层面。
在真正开始介绍公共信息平台的设计原则之前，先说两种通用的设计思路：
1. 自上而下设计：指的是从根元素进行分析，一步步进行分层设计。
2. 自下而上设计：指罗列能够确认的底层模块，对模块进行汇总总结，一步步进行总结层次，最终形成最上层。
分别考虑两个设计模式的优缺点：
1. 自上而下设计：
优点：
l 可以从上层把控整个系统的层次结构。不会出现层次混乱的问题。
l 前期层次较少时，层次明确，设计简单。有利于前期工作开展。
l 给领导更好的进行汇报。
l 可以更好的进行组织安排，比如把不同的层次分给不同的人员来进行设计。但总体架构不收影响。
l 某个模块设计完成之后，可以提前进入开发阶段。
缺点：
l 不利于风险的识别。子节点的风险尤其是影响整个系统的风险在一开始无法识别出来，积极应对，容易总成项目的重大问题。比如成本增加，进度拖延。
l 不利于整体架构设计，自上而下设计，一开始的分层依据不够，容易在后续分层时对上层架构继续大规模的调整。
l 层次变多之后，层次之间的关系复杂度变高，设计难度加大。甚至出现自相矛盾的设计。
典型应用场景：
售前人员在进行系统方案设计时采用的典型方法。可以根据用户的要求，按照用户目的形成业务模块，设计出完全符合用户业务的模型。
2. 自下而上设计：
优点：
l 可以充分考虑各阶段的风险问题，将风险提前罗列，提前准备应对措施，减少项目失败的风险。
l 设计上因为考虑的更加全面，几乎不会出现重大的返工问题。
l 设计越往后难度越小。
缺点：
l 前期理清底层单元模块困难，容易造成逻辑混乱，设计难度大，不利于前期工作开展。
l 由于设计的特性导致，必须所有的设计完成之后，才能进入开发。
l 工作组织不好安排，更多的是依赖于经验丰富的人员继续风险识别。
l 前期工作琐碎，不容易见成果，因此不容易跟领导进行汇报。
典型应用场景：
技术框架或者小型系统的系统设计，在做一个小型的系统时，由于结构比较清楚，因此可以考虑各个方面的影响因素，设计完成之后，功能比较稳定。尤其是技术框架的设计，一定会充分考虑各种细节之后，才会进行整体的开发。
实际工作中一般不会直接使用其中的一种，比如一个信息系统的开发，一般是由开发经理或者架构师将所有可能的风险或者问题提前罗列进行各种的风险评估，计划审定，然后按照自下而上的方式进行文档编写，规划制定，方便领导审批，工作组织，计划制定。
对应到我们的公共信息平台，我们也建议采用复合型的架构模式。
以自上而下为主，但是充分考虑各个阶段的问题。通过各个角度的架构来验证系统是否合理。
也就是说：
1. 由于现在缺少用户明确的需求确认，只有几分简单的指南和国标，因此在设计时首先保证大的框架不错，从上而下设计。以自上而下为“纲“，为设计主线。
2. 在进行设计时，考虑到工期的问题，建议在整个设计的过程中，充分考虑各个阶段的问题和风险，随时将能想到的问题和风险进行确定。作为设计的“页子”，作为设计的“副本”。
a) 将大家理解不同的术语和概念，提前统一。
b) 将大家提出的问题，提前确认。
c) 将大家提出的风险，提前进行预防和规避。
3. 详细的问题列表和风险列表，有利于制定更加完善的技术架构和开发计划。保证产品正常的开发进度。
4. 从多个角度，用户问题角度，业务流程角度，技术架构角度等来对架构进行描述整理，以及验证，保证架构的合理性。不能只考虑业务架构的合理性不管技术实现难度，也不能只考虑技术架构的方便性，不考虑业务实际情况（专门文档介绍）。
原文地址：http://www.cnblogs.com/sdjnzqr/p/4019451.html
