有时听到开发人员抱怨系统运行速度慢，开发效率低，代码和重复的工作太多。我都要仔细听来，感慨颇多。这种情况不仅仅是其他人的项目，我自己的项目也有这种情况。
最常听到的是，系统分了这么多层次，每次加新需求，加入新的对象，都要在每一层作修改，比如，在服务端，先加在Model层，然后再修改数据持久层，然后再修改业务层，再修改界面或服务层等，修改完了服务端，还要在那些依赖于这些服务的客户端进行逐层的修改。这种修改往往是重复率很高的，比如，在服务端的一个层的某些方法，可能在另外一层对应存在，并且名称和参数，返回值都是一样的，只是为了分层的需要而加入，做了一个代理而已。并且，这种重复不但要在服务端出现，还会在客户端出现，而且可能会在各个层次的单元测试的代码中出现。所谓牵一发而动全身，是也。
还有这样的抱怨，本来，我们的系统直接访问数据库，通过ADO或者直接使用持久层的软件，做项目非常顺利。但是，自从加入了服务层，似乎要SOA，变得松耦合，我们的运行效率和开发效率就每况愈下。原来的数据访问层要修改，要增加新的数据访问层，并且有新的服务端的业务逻辑层，每个层次都要单元测试。做了这些后，我们的系统，仍然是原来的部署方式，但是运行效率却大大下降，用户明显感觉访问速度有影响。
构架，这个被很多开发者谈其必顶礼，观之须仰视的东西。本来是为系统提高可用性，为开发提供可扩展性的，提高开发和协作开发效率。却变得降低了可用性，降低了开发效率。
开发人员的面前受到了质疑，用户也会开始抱怨，因为运行效率的降低，以前上传一个大文件仅需要几分钟，现在变成十几分钟。技术都是在进步的，你们改进了框架之后，不但没有进步，反而退步了，这就是领先的框架吗？
为了解决系统的扩展和大规模开发的需要，以及更多的外部用户和开发队伍的参与，没有一个好的框架是难以承担这些的，所以，好的框架，我们现在比较认可的松耦合，面向服务，分层开发都是可行的。
但是，框架考虑的不仅仅是这些，还需要考虑系统的运行和开发的过渡。
不能忽视构架在小系统时的效率。我们的目标是让系统变大后，可以很好的扩展，很好的运行。但这个目标是假想的，最真实存在的，是我们目前的小系统。没有小系统是的高效可用，可能就没有系统扩大的机会。
不能忽视构架在小系统时的开发效率。我们想象着有更多的团队在我们的构架下开发，按照我们的模块API和标准开发插件和模块。但是，如果每个插件或模块的开发都向上面说的繁复，开发和调试巨费劲，那么可能就不会吸引更多的外部团队。
那么，如何解决这种构架之累呢。
首先，理解框架的本质。
框架试图通过对要建立的系统进行物理或逻辑的划分，使系统中的每个单元既独立，又和谐地工作，协同完成业务需求，而且划分后的单元，可以通过并行开发的方式，有更多的开发人员参与其中，使规模开发更简单高效。
划分单元的目的，也使每个单元各司其职，功能相对单一，如果需要其他的功能，可以调用系统中的其他模块，但又较小地受到其他单元的影响。达到最大化复用，统一了开发模式，减少了重复工作。
所以，我们看到，构架是一个思想，就是让专业的单元，去作专业的事情。理想状况下，一个开发团队或一个小组，仅在一个模块中进行工作，而不必在他不擅长的模块工作。所以上面开发人员遇到的一个人要写多个单元的代码，就是在不专业的模块中工作，自然变得非常之累。
其实更重要的是，如何设计我们的构架。
如何设计构架，就是要知道如何划分系统，如何物理和逻辑地划分系统，如何根据系统规模和开发团队计划构架。
如果我们能够将构架的系统规模计划好，了解当前开发团队的现状和后续的发展情况，设计的构架才能既适合目前系统，还可以在未来的发挥作用。
划分的方式可以是物理的，也可以逻辑的。
物理划分可以理解为系统的单元在不同的系统环境中运行，不同的服务器，不同的服务空间，不同的主机环境，不同的操作系统，不同的用户，不同的内存空间，不同的实例等，这样的划分一般是跟系统的运行和部署相关的。
逻辑的划分可以理解为对结构的划分，这个划分不必考虑物理结构，仅就同一类的业务进行组织。这个业务包括真正的用户的业务，已经我们代码的逻辑结构。
代码结构最简单我们可以听到的，3/n层，或者是MVC或者是MVP的模式，甚至在一个层次内更细分多个层次或网状结构，这个的争论很多，我认为这些模式或分层之间都无所谓好坏，有逻辑总比没有逻辑要强，代码结构的逻辑其实并不是特别复杂，有3层或3个单元是比较好的选择，稍稍多1～2个单元也是可以的。
重点在用户的业务逻辑。因为用户的业务逻辑中，涉及的对象比较多，比如账户和资金，产品和销售等等，涉及的对象（仍然是对象）往往从几个到十几个甚至成百上千。这些对象有些是我们可以控制的，在我们系统的内部，有些是在系统的外部，是同上面说的物理划分相关的，复杂的物理结构往往让我们有时偏离方向。
其实，用户的业务逻辑仍然是非常简单和清晰的，是同物理结构没有关系的，无论哪个资金数据库在内部数据库还是外部服务，在我们的业务逻辑设计中，他就是一个对象而已。所以，这就是我们强调的，物理和逻辑的划分。
根据系统规模和计划进行构架设计
根据团队规模和计划进行构架设计
设计工具和部署工具对构架设计的影响
未完待续