架构的第二步——技术

下面我们就对技术视点进行一定深度的剖析，说的直白一点就是对技术来进行切割，即对服务的切割，我这里来介绍技术切割的这样几把刀，不多说了。

对技术进行切割绝不是一件特别简单的事情，最开始的时候，我是完全没有思路，不过老师的一句话让我顿时豁然开朗，他说你想想应该怎么样去写代码，说到这时，我先把我们通常用java编写一个web工程的代码结构写了出来，Action层，Service层，Persistable层，还有Entity层，老师看过之后，笑了笑，说我深受java的影响，不过也同时揭示了一个道理，就是mvc的思想，然后老师又说，这只是把一个软件进行纵向的切出几块，还有没有横向切的，比如一些通用的组件，老师还说横切是一种AOP的思想，这时我就想到了权限管理，我们写代码的时候通常会把权限管理还有日志的记录都是用AOP的方式进行切面编程，老师点点头，说这些公共的组件通常都会拿出来进行AOP的集成，但是大家考虑过这是为什么呢？就拿权限校验为例，通常这些代码存在于项目的各个角落，有一些大的项目甚至有上万个地方都要用到这些代码，如果我们不把这些公共的东西拿出来的话，假如有一天，我们权限校验的这个接口改变了，里面多了个参数，那我们有没有想过，这得多大的工作量啊，所以我们有必要把这些公共的东西拿出来，这样我们只需要改这些切面组件里面的代码就可以了。在我写的这些文章中用到了很多类比的方法，这样更方便把一些抽象的难以理解的知识转换成通俗易懂的东西来呈现给大家。

     通过我们对上述图片的理解，我们可以清楚的看到软件业务的切割与服务的切割，是两个完全不同的视角，不过服务的切割时基于业务的切割，业务的切割是服务切割的基础与落脚点。    

下面我们来介绍一种纵向切割的一种分析方法——鲁棒分析法（如下图所示），这种分析方式OO的思想贯穿于始终我们看到这里面有三个对象的概念：

1：实体对象：这种对象通常来自域模型，说白了就是从现实世界从抽象出来的，通常用来描述具体的实体，一般都会映射到数据库的表格或者文件中。

2：控制对象：主要用于体现应用程序的执行逻辑，将其抽象出来，说白了就是它自身怎么变化都不会影响用户体验以及数据库中的表。

3：边界对象：这也是最难理解的，通常是指用来完成参与者（用户，外部系统）与系统之间交互的对象，如接口，对话框，菜单，表单等。

  

同时鲁棒分析法也涵盖了分层的概念，我们不难发现，用户只能和边界对象之间进行交互，而控制对象可以与边界对象和实体对象之间进行交互，而实体对象只能和控制对象之间进行交互，下一步我们就拿bug管理系统来进行鲁棒分析一下，演进行鲁棒分析，首先要找到使用者，在缺陷管理系统中，该系统的使用者有开发人员和测试人员，我先说测试人员提交缺陷这个功能，接下来我们要找到边界对象，首先测试人员到登陆到主页面，主页面上肯定有一个添加缺陷信息的按钮，点击这个按钮，就会弹出一个缺陷表单填写的界面，填写完主要信息后点击确认/提交按钮后，其中的主页面——添加缺陷按钮——缺陷表单页面————选择指派人的选择框——问题发现方选择框——提交按钮，这些都是边界对像，如下图。

  

下面让我们来一起找一下控制对象和实体对象。大家只要静下心来，把自己当做一名测试人员设身处地地去想整个过程，不断去完善就可以画出图。

 

下一步我们要构建交互图，通过这个图形的呈现，我们基本上可以把所用到的方法都可以推导出来，如下图。

  

下面我想说一下软件接口的设计，大概要掌握这样几个原则，首先要遵循最小接口原则、自我描述接口、接口分离原则、稳定接口原则。最小接口原则，顾名思义，就是小，不过这个小实在是难定夺，有的人在设计接口是把所有想到的方法都写在里面，这时候就要做一些定夺，可能有一些方法根本不需要，获取可以和其他方法共同完成一个功能，这样就可以做舍弃，接口分离原则是这样的，如果有多个客户使用这个接口，那么我有必要定义多个接口，然后去实现这些个接口，为什么要这样设计呢，加入A用户想要改变这个接口里的方法，那么我们只要更改对于A用户开放的接口以及其实现类，对B,C用户都没有影响。稳定接口，也就是稳定的接口，运行了很长一段时间都不需要变化的接口（这是我的理解，可能不正确），其实还有很多原则了，我会慢慢去探索的。

接下来我说一下弹性的设计，我觉得这个好难，因为很难把控软件未来的变化，以及发展方向，不过通过老师的讲解，我总结出了一个原则叫做万物归一，比如我在软件生命周期管理的软件使用过程中，刚开始的时候只加入了bug管理系统，后来我又想加入风险控制，以及任务管理模块，这时我们就要想一下，这三个系统可以归为一类统一都叫做WorkItem，这个之前我也说过，其实就是一种封装的思想，不过怎么样才能从技术上解决上述的问题呢（万物归一，而且可以不用考虑使用的语言），这时我们会想到一个强有力的东西就是xml文件，通过配置就可以简单地解决上述问题了，还有一种变化可以通过设计模式来解决问题，EA对设计模式进行了很好的融合，所以我们以后要仔细留意一些设计模式，比如工厂模式、代理模式等，通过这些设计模式即可解决变化之道。老师给总结了几点，要问这样几个问题。

1：这种变化是不是单一方向的编码吗：

答：如果是，设计模式即可解决。

2：这种复合变化是否可以分解成2——3种变化？

答：如果是，复合应用设计模式即可解决。

3：这种变化是“值 类型”的变化吗？

答：如果是，配置式即可做到（XML，数据库，纯文件）

4：这种复合变化是逻辑判断型的变化吗？

答：如果是，可以通过脚本方式来解决这种变化。

今天就说到这吧，其实还有好多的东西，我以后会慢慢补充的，也请大家多提提意见和建议。下回我们先讲一下数据库的设计。