1.在一次的操作中不要涉及到过多的数据表，数据表过多---导致编码复杂，易出错，这样就是在一个方法中做了很多的事情

2.业务规则对应着业务方法

3.现在关注一下数据，我们在页面上看到的所有东西都是数据，那么如何将这些数据抽象成为你想要的对象呢？

4.尽情放开你的思想，你随便可以创造任何的对象，没有对错之分，在你的世界里你就是主宰，你想怎么操作就怎么操作
所以请不要约束你的思想，尽情的构造你自己所认为的对象世界

5.要有一个概念”用户交互“”使用场景“”交互过程“，在这个分析互动的过程中可以看清楚很多的问题

6.我们先要脱离数据访问层，直接在业务层，在系统中看待业务对象，不要使数据库的设计影响我们对系统的实现

7.不能根据数据库model来决定你的业务对象，业务中要使用什么对象完全是具体业务所决定的

8.原来架构是针对业务逻辑来说的

9.业务逻辑决定着你的数据库设计，它是一个上层的东西

10.从数据库上可以推测出你的系统业务逻辑

11.数据库的设计是一个底层的东西，归属于业务逻辑，不要本末倒置

12.要学会画出系统对象业务交互图

13.数据库中的表对象不等于业务对象这一点要注意

14.VO和DTO差不多说的是同一个东西

15.所谓的ORM其实就是将数据库中的对象进行建模放在程序对象中去使用

16.对象交互的消息模型是OOP更为本质的特征

17.消息关注的是对象间的接口和交互，在构建大的系统的时候重要的不是对象/模块的内部状态，而是它们的交互

18.封装是划分了基于类的静态的代码边界，使得类的private代码修改不影响外界，而不是对于动态对象的保护

19.常见的一些实体 分类和产品 品牌和分类

20.我们可以关注一些微软内部类对象的封装过程，我想这些大师的设计 应该是非常高明的

21.和使用火车头是一个道理，应该更多的去使用，才能灵活的变通起来

22.按照需要定义你的对象

所思所想 业务逻辑