上章详细讲了EnterpriseFrameWork框架中的每个分层，这都是从技术层面来说明，也就是我们知道怎么来建一个控制器或一个业务对象，但开发过程中应该建一个什么样的控制器或业务对象了？本章的主要内容是说明根据系统业务、客户需求如何来设计合理的控制器和业务对象。
文件要点：
1.粗略介绍系统分析设计过程
2.框架分层结构怎么结合业务
大概介绍一下我对开发一个系统的分析设计过程吧，决定开发某个系统后，肯定是先了解系统相关业务内容，根据自己的见识这个应该属于哪一类的系统，是类似进销、还是收费系统或其他，也在网上也找找有没有类似业务的系统；这些在开发一个系统前都是很值得参考与分析的资料；这样你心里也有了个底，自己团队能不能做出来，要花多长时间、多大资源才能完成；心里有底后就可以三板斧完成整个系统分析设计过程，
第一，根据客户需求，结合业务场景画出一些业务活动图、用例、实体等
第二，接着根据经验或理解了设计出界面原型和数据库结构
第三，然后针对关键性系统问题进行领域分析得到领域对象模型
这样系统的分析设计已初步完成，然后就是把设计转化为代码，以后随着对业务的深入理解而进行不然迭代提升；而且个人觉得用例图与领域模型可以很好的帮助自己在业务方面的理解；
再看下面几个问题在修改代码的时候经常碰到，
1）修改一处联动性功能问题，往往一串代码文件，因为把实现代码分散在多个代码文件中而没有放在一个文件中；
2）修改一个关键性系统问题，往往会修改多个模块的代码才能彻底解决，因为你并没有把解决这个问题的代码封装成业务对象；
解决这两个问题就是我们的代码的分布一定要与实际业务要对应；让我们可以快速找到需要修改的代码并花最小代价完成修改；
用例：是描叙在逻辑上相对完整的功能流程；
领域模型：专注于分析问题领域本身，发掘重要的业务领域概念，并建立业务领域概念之间的关系；
我们把用例和领域模型换成纵向和横向两个角度来看上面两个问题，一个联动性很强的功能问题都对应着某个用例，而关键性系统问题都应该进行领域分析得出领域对象模型；所以把修改内容控制在一个用例中或一个领域对象模型中，就很容易控制和实行；与功能问题密切相关的不就是界面与Controller控制器，而与系统级问题相关的不就是ObjectModel业务对象；
Controller与ObjectModel没有包含或被包含的关系，两者完全是平级的；一个Controller可以调用多个Object，而一个Object同样可能被多个Controller调用；为什么这么对应，也是方便更容易的理解代码，保持代码阅读的连贯性；如果在代码设计过程中没有一个指导性思想，是很容易混淆代码文件的，如：纠结的是一个类或方法不知道放在哪更合适，就跟给多个控件或变量起名一样困难；
由此在项目中使用框架的过程中，反过来再看之前的系统业务分析与设计得出：框架中的Controller对应业务中的用例，ObjectModel对应业务中的领域对象模型；见下图
由于本章的内容没有什么具体的代码和实例，都是一些形而上的见解，所以难免会有个人的局限性，但是说的都是在实际项目中的经验和领悟；这些东西个人觉得讲解一些个人经历来进行引导性思考，比摆出一套完整的理论应该更合适；比如系统分析师或系统设计师，不可能通过学习两本大牛的书籍就能成为的，而是不断在项目中通过你的经验累积磨练而成的，一个系统设计师把自己的方法与套路交给你，而你也不是学会了就能够成为一个系统设计师的；既然这样那还不如讲讲个人经历，讲讲走到每个阶段的心情与感悟，这样可能会更容易产生共鸣；