1、表现层（UI）：展现给用户的界面，用户在使用一个系统 的时候他的所见所得。
2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操 作，对数据业务逻辑处理。
3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、 删除、修改、更新、查找等。
4、实体层（Model）：倾向于业务逻辑层（三层），用来封装数据，三层间传送数据，不知道各个层次，独立于三个层次，Model不引用各层次，但三个层都会引用Model。
优点：低耦合、高重用和使用、低开发成本、快速部署、可维护、利于软件开发管理
二、MVC 1、概念它是XeroxPARC在八十年 代为编程语言Smalltalk－80发明的一种软件设计模式，它强制性的使应用程序的输入、处理和输出分开。使用MVC应用程序被分成三个核心部件：模型、视图、控制器。它们各自处理自己的任务。
M即Model(模型层)，主要负责出来业务逻辑以及数据库的交互
V即View(视图层)，主要用于显示数据和提交数据，是用户看到并与之交互的界面。
C即Controller(控制器)，主要是用作捕获请求并控制请求转发
视图
能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。
模型
模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。
控制器
控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后用确定用哪个视图来显示模型处理返回的数据。
小结：
首先控制器接收用户的请求，并决定应该调用哪个模型来进行处理，然后模型用业务逻辑来处理用户的请求并返回数据，最后控制器用相应的视图格式化模型返回的数据，并通过表示层呈现给用户。
大部分Web应用程序都是用像ASP，PHP过程化语言来创建的。它们将像数据库查询语句这样的数据层代码和像HTML这样的表示层代码混在一起。经验比较丰富的开发者会将数据从表示层分离开来，但这通常不是很容易做到的，它需要精心的计划和不断的尝试。MVC从根本上强制 性的将它们分开。尽管构造MVC应用程序需要一些额外的工作，但是它给我们带来的好处是无庸质疑的。
3、一条创建软件的好途径如果你要隔离模型、视图和控制器的构件，你可能需要重新思考你的应用程序，尤其是应用程序的构架方面。如果你肯接受MVC，并且有能力应付它所带来的额外的工作和复杂性，MVC将会使你的软件在健壮性，代码重用和结构方面上一个新的台阶。
4、好处与不足好处：
首先，多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。无论你的用户想要什么界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可最大化的重用你的代码（视图）。
由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到 Oracle，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确的显示它们（模型）。
可以使用控制器来联接不同的模型和视图去完成用户的需求（控制器）
不足：
由于它没有明确的定义，所以完全理解MVC很不容易。使用MVC需要精心的计划，由于它的内部原理比较复杂，所以需要花费一些时间去思考。同时由于模型和视图要严格的分离，这样也给调试应用程序到来了一定的困难。每个构件在使用之前都需要经过彻底的测试。一旦你的构件经过了测试，你就可以毫无顾忌的重用它们了。
由于我们将一个应用程序分成了三个部件，所以使用MVC同时意味着你将要管理比以前更多的文件，这一点是肯定的。好像我们的工作量增加了，但请记住它的好处
MVC并不适合小型甚至中等规模的应用程序，花费大量时间将MVC应用到规模并不是很大的应用程序通常会得不偿失。
三、相同与不同细分后：View(UI)、BIZ（BLL）、DAO（DAL）、Entity（Model）、Controller
MVC把BIZ（BLL）、DAO（DAL）、Model（Entity） 统一称之为 模型(MODEL)，得View、Controller、模型(MODEL)
三层暂未体会到控制器的存在，完全是：UI、DAO、BLL
相同点：
同样是架构级别的，他们都有一个表现层；
把视图设计与数据持久化进行分离，从而降低耦合性，易于扩展，提高团队开发效率。
不同点：
三层架构是最基本的项目分层结果，而MVC则是三层架构的一个变体，MVC是一种好的开发模式，我们可以用它来创建在域对象和UI表示层对象之间的区分。
三层”中典型的Model层是已实体类构成的，而MVC里，Model则是由业务逻辑与访问数据组成的，它的分层也是为了结构清晰和低耦合，（高内聚：单一责任；低耦合：模块独立），区别比较大的就是三层架构中没有Control层，而是由单个页面上的控件的事件处理页面与业务逻辑之间，而MVC中control层是作为联系视图层和Model的纽带，使得整个项目的结构更加清晰，降低了耦合性。
四、如何取舍
1、高层模块不应该依赖低层模块，两者都应该依赖于抽象（抽象类或接口）
2、抽象（抽象类或接口）不应该依赖于细节（具体实现类）
3、细节（具体实现类）应该依赖抽象
抽象：即抽象类或接口，两者是不能够实例化的。
细节：即具体的实现类，实现接口或者继承抽象类所产生的类，两者可以通过关键字new直接被实例化。
而依赖倒置原则的本质骑士就是通过抽象（抽象类或接口）使各个类或模块的实现彼此独立，不相互影响，实现模块间的松耦合。但是这个原则也是6个设计原则中最难以实现的了，如果没有实现这个原则，那么也就意味着开闭原则（对扩展开发，对修改关闭）也无法实现。
依赖倒置有三种方式来实现
1、通过构造函数传递依赖对象
比如在构造函数中的需要传递的参数是抽象类或接口的方式实现。
2、通过setter方法传递依赖对象
即在我们设置的setXXX方法中的参数为抽象类或接口，来实现传递依赖对象
3、接口声明实现依赖对象
public class Tutu {
//JIM是个女孩，会煮面
public void cook(Noodles noodles)
{
noodles.eat();
}
}
面条（目前只会煮面）
public class Noodles {
//吃面条
public void eat()
{
System.out.println("JIM吃面条...");
}
}
涂涂坐在家里吃面（场景类）
public class Home {
public static void main(String args[])
{
Tutu tutu = new Tutu();
Noodles food = new Noodles();
tutu.cook(food);
}
}
运行结果：JIM吃面条...
但是这有个问题，涂涂只会做面条，不可能每次都吃面条吧，天天吃面吃死你，所以在上面的Tutu类中的cook方法中，如果涂涂会做其他吃的，那岂不是更好。于是她向家庭主妇迈进了一步，使用了依赖倒置原则。
也就是JIM通过学习还可以焖米饭，炒鱿鱼（虽然听着不爽，但是很好吃），京酱肉丝啊等等。要想在代码中实现，就需要实现两个接口：ITutu和IFood
public interface ITutu {
//这样就会做很多饭菜了
public void cook(IFood food);
}
实现类
public class Tutu implements ITutu {
@Override
public void cook(IFood food) {
food.eat();
}
}
食物接口
public interface IFood {
public void eat();
}
这样就为扩展留出了很大的空间，方面扩展其他的类。也不会对细节有变动。以后涂涂想吃什么学一下就可以自己做了
实现面条
public class Noodles implements IFood {
@Override
public void eat() {
System.out.println("涂涂吃面条...");
}
}
实现米饭
public class Rice implements IFood {
@Override
public void eat() {
System.out.println("涂涂吃米饭（终于吃上米饭了）...");
}
}
场景类：JIM在家里开吃了，想吃什么直接做就是了
public class Home {
public static void main(String args[])
{
//接口使不能实例化滴
ITutu tutu = new Tutu();
//实例化米饭，涂涂可以吃米饭了
IFood rice = new Rice();
//吃面条
//IFood noodles = new Noodles();
tutu.cook(rice);
}
}
这样各个类或模块的实现彼此独立，不互相影响，实现了。
参考"scrum in action"一书，首先要定义开发的产品的利益相关者，它的英文术语叫做：stakeholder。
参考百度百科的定义：
管理学意义上的利益相关者（stakeholder）是组织外部环境中受组织决策和行动影响的任何相关者。
也就是组织外部的，但是不限定于客户，也包括供货商或者其他相关联的人。总之这个词的含义非常广。因为如果将组织定义为开发产品的一个团队，那么该组织之外的人也可以包括同属一个公司或者部门的其他团队成员，只要他们和这个产品有某种联系。
scrum 维基百科中定义是：
利益相关者（客户，提供商）影响项目成功的人，但只直接参与冲刺评审过程。
从以上的定义可以看到有几点值得注意：
1. stakeholder不仅是客户，只要影响到项目成功的人都可以算
2. stakeholder是scrum项目组之外的人，因此可以是同一个公司或者部门的
3. 如果可能，邀请stakeholder代表参加项目的sprint review会很有帮助
问stakeholder几个问题，比较容易找到goals：
1. 你的业务目的是什么？
2. 为何你需要这款产品？
3. 你如何衡量目标的实现程度？
当你据此找到一些goals后，可以用SMART原则来检查每一个goal：
1.specific
每个人对goal有相同的理解
2.measurable
能客观衡量goal是否达到
3.achievable
stakeholder同意关于goal的定义
4.realistic
我们拥有足够的资源完成goal
5.time-based
我们有时间来完成该goal