课程的最开始，是没有用任何架构就做一个《点点点》这样的项目，做的方式就是用拖拽加一点代码的方式。

但是这种方式有一个问题，就是对象之间的相互访问没有规则也没有限制，在项目规模变大时就一定会混乱。

于是引入了一个规则，只有自顶向下的时候可以直接访问对象或者调用对象的方法。自底向上的时候使用事件或者委托。而在讲这个规则之前还介绍了对象之间的三种交互方式：方法调用、委托、事件。

然后自底向上和自顶向下再向上对象之间的三种交互方式构成了一个大的前提，后边比如层级、业务模块等只要有高低之分的我们就都用这套规则去约束了。

再往下就介绍了一个简单的模块化，介绍了一个单例的模块化。我们在设计的时候经常听到一个原则，就是高内聚低耦合，高内聚的意思就是相同的代码放在一个地方去管理，低耦合就是对象之间的引用不要太多，最好就是单项引用或者没有引用，或者是有一定的规则去约束如何互相访问的。

再往下就引入了一个概念，就是Model。Model是为什么引入的呢？是因为有一些数据，需要在多个地方去共享，比如角色的攻击力，需要在UI界面上显示，或者计算一个伤害的时候需要使用，以及存储这个攻击力也是一种共享方式。这一类数据都放到Model里管理起来。

一些临时的数据（不需要共享）是不需要放在Model里的，直接在表现层里使用这种数据即可

引入完Model之后就要考虑一个问题，就是其他的地方怎么跟这个Model进行交互，一般的方法就是用类似MVC的方式，其中的Controller管理的逻辑分成了交互逻辑和表现逻辑。

大家都说MVC中的Controller代码容易臃肿起来，罪魁祸首就是交互逻辑，只要是有数据操作或者变更游戏数据状态的逻辑都是交互逻辑，而这部分的逻辑是非常多的，要想解决Controller代码臃肿的问题，一般的共识就是引入命令模式，让Command去分担Controller的交互逻辑，Controller仅仅是调用相应的Command即可。

引入了Command之后，Controller就变成了比较薄的一层了，而Command并不适合负责所有的交互逻辑，比如有的交互逻辑最好还是统一放在一个对象里，比如分数统计、成就检测、任务检测等，如果分数统计这种逻辑分散在各种Command里，会非常不好管理，而分数统计实际上是一种规则类逻辑，比如打一个敌人得多少分等等，这种逻辑最好是统一放在一个对象里管理，于是就引入了System层，System层就是为了统一管理交互逻辑而引入的，这些系统一般会写很多死代码，如果全都在Command里面实现，代码量又多又重复，这同时也是高内聚的一种体现。

技术上来讲，System层可以替代Model层。但是不建议，一些原始数据如配置数据还是最好在Model里

到这里核心架构的一些概念就有了雏形了，像事件机制，BindableProperty等都是一些通用的工具。

总之架构中的每一个概念的引入都是为了解决特定的架构问题的，并不是为了做成架构而引入的，然后只要不断地去解决这些架构问题，就会慢慢迭代出来一个比较成型的架构。

到了第二季，对一些架构本身的问题做了一些改进，比如BindableProperty去掉IEquatable接口，实现了完整的CQRS机制（引入了Query）