上图是顶层架构的俯视图和侧视图。第一张图是俯视图，坐在飞机上看，整个顶层架构最外层的是功能，中间的是业务操作，内层的是数据。功能对应业务系统的用户界面，操作对应业务系统里的服务，数据对应业务系统的数据存储如数据库。第二张图是剖面图，切一刀来看，上层是应用，中层是服务和框架，下层是基础设施数据中心。从图中的服务层可以看出，服务的归类跟业务流程的归类有很大关系。
4.2、网站功能规划
网站功能规划就是功能的重新划分，对照着架构现状，未来的功能应该如何调整？如案例中的国内网站功能规划，分别画出了全局功能图、采购商功能图、平台商功能图和供应商功能图。其实在做网站功能规划的时候，更多需要考虑现状，而不是未来调整的部分，如果没有很大问题，则不做调整，尊重历史。因为有些东西（如名称）用户已经使用很久了，调整往往比较难，合理大于准确。
4.3、应用规划
系统是什么，系统=元素+关系。应用架构是什么？应用架构=应用+架构。应用就是系统的最小单元，应用分类和应用编号则构成了应用关系即应用的架构。如上图中的案例，应用分类新建了框架FX和公共业务系统CBS，在原有的200多个应用中并没有这两个产品线，而是分布在了不同的业务线中，从而导致重复建设。应用编号是给每个应用分配一个六位的数字ID，就如同我们的身份证一样，头两位表示产品线，中间两位表示子系统，最后两位表示应用，如100206。应用编号是应用管理、依赖和追踪的基础，集中式日志和监控框架都有使用到应用编号。
4.4、SOA规划
SOA规划就是接口规划，它的归类与商务模型中的业务流程有参考对应关系。上图案例有五个服务中心：预订服务、订单处理服务、产品供应服务、财务结算服务和公共服务。每个服务只需要实现一套自己的逻辑，我们的前台、后台、接口、作业小应用等都可以调用，服务的逻辑跟我们的业务逻辑是一致的，修改代码的时候只需要改一个地方就可以影响到所有调用到这服务的前端应用。
4.5、分层架构
分层架构看似很简单，但保证整个研发中心都使用统一的分层架构就不容易了。那么如何保证整个研发中心都使用统一的分层架构呢，以达到提高编写代码效率、保证工程统一性的目的？先简单介绍下当前两种比较流行的分层架构体系，一种是领域架构：仓储层Repository Layer、领域层Domain Layer、应用服务层Application Layer、表现层Presentation Layer和基础公共层Infrastructure Layer，请见第一张图；另一种是相对传统地分为三层：数据层Data Layer、应用逻辑层Business Layer和表现层Presentation Layer，请见第二张图。
领域架构和三层架构之间有什么区别？我们是这样认为的，在早期我们做三层架构的时候，大都以表来做驱动的，在做领域架构的时候，大都以业务逻辑来驱动的，两者的区别确实比较明显，但到了现在，如果都以业务逻辑为中心的话，实际上两者并没有本质区别。当时，我所在公司采用了第二种分层法，我们希望把分层做得极简，也就是说哪怕刚毕业进来的员工，在分层时基本上也不会乱。而相对第一种分层法，第二种分层法简单很多。每一个应用的代码量都不应该很大，一旦工程变得过大，我们就会把它适当拆分，而不是全部放在一个单块应用里。总之，我认为分层越简单，整个软件结构就越清晰，代码就越容易统一。把工程做得极简，才有利于复制，有利于业务的快速构建，有利于规模化、稳定可靠。
4.6、数据库规划
数据库是整个信息系统中生命周期最长、最难修改的部分，所以要加强规划。数据库的设计至少要提前两步，具体根据高层E-R图和数据设计来新建数据库，早建要比晚建好。数据库调整的代价大、周期长，长时间产生的问题，需要长时间来解决，先在新库里解决新表，再根据当前业务和应用的需求，逐步调整旧表。
4.7、物理规划
物理架构的规划内容包括集群规划和域名规划。首先是集群规划。20 倍规划、5 倍设计和 1.5 倍实施：规划和设计要大一些，但实施时小一些，这样不仅便于将来的扩展，也节省了当前的费用；两个逻辑网络：一个内网和一个外网，两个负载均衡，两个防火墙，安全隔离内外网；四条产品线：国际、国内、新业务以及公共业务，单点登录和企业支付网关等公共业务也属于一条产品线；六个集群：Web 集群、SOA 集群、中间件集群、数据库集群、Job 集群和 ITD 集群。以上横向集群与纵向产品线形成了一个矩阵结构，也基本确定了网络基础架构。对于域名规划。对内的域名该改的改，该停用的停用，该合并的合并。对外的域名要尽量少改，要改的话也要有历史继承性（如跳转），要尽量减小对用户的影响。
4.8、其它
除以上架构规划外，还有一些其它重要项，如源代码管理规划、文档管理规划、技术选型和团队分工。为什么还要做这些呢？因为统一了源代码怎么放、每个部门的文档怎么放、将来要用什么工具版本，才利于团队的协作，基于统一的环境才能有更高层次地提升。对于团队分工，需要逐步对齐组织架构与系统的架构规划。对于技术选型，需要注意中间件的引进，要有节奏性，力量要相对集中，要小规模试点，找非核心项目，试用成功后再进行大规模推广。
五、架构实施
做完架构规划后，就是架构实施落地了。我们的架构实施整体思路是：树目标、给地图、立榜样、抓重点、造文化、建制度、整环境、组建架构部。架构部内招几名老程序员，外招几个架构师。内部走出去，提高眼界。外部牛人请进来，落地了解历史和业务。技术建议是：SOA服务化、基础设施平台化、公共业务服务化、加强项目概要设计。当研发团队达到200多人、有了几百个应用，且在故障不断的情况下，不能与以前一样没有设计就开始编码，而是做加强项目概要设计及评审。后面的补与前面的防，两手都要抓，两手都要硬。具体计划是：Roadmap分步实施，改造一期、改造二期、改造三期，近细远粗、实事求是、逐步细化、逐步完善。不断立技术改造项目，不断将技改与业务研发项目相结合，技改即是工单、工单即是技改。避免对业务过多地影响，并不断有业务价值输出，这是架构改造得以持续实施的关键！
以上简单地介绍了总体架构的编写方法，我们的编写思路是先了解业务，建立企业商务模型，主要包括静态的商务主体
