假设我们要制作一款战棋游戏，其中技能是一个单独的系统，本着独立系统负责独立功能的原则，他的功能是：
1. 能够结合人物属性，提供与技能相关的可操作数据（如战士A的技能都可以在哪些格子释放，需要玩家选择其中一个格子释放）
2. 能够控制技能的整个释放流程
通过上图我们可以看到，这个技能系统非常贴合经典的MVC设计模式：
技能的核心数据就是Model，技能的计算部分是Controller，技能的释放流程（展示过程）是View。
那么，这个系统我们可以按照如下思路去设计（按照调用顺序排列）：
1. 将技能的核心数据存储在存储单元中，可能是json文件或者本地数据库等。核心数据可能包括：id,value1,value2,name等
2. 创建可操作数据运算中心SkillOperateController，主要实现这个方法：
public OperateData CalOperateData(SkillData skillData, RoleData roleData){
//todo
}
3. 拿到OperateData后，通过SkillView去展示操作选项，同时接收玩家的操作结果，得到OperateResult
4. 创建技能结果运算中心SkillResultController，主要实现这个方法：
public SkillResult CalSkillResult(OperateResult or){
//todo
}
5. 通过SkillResultView来展示SkillResult，并最终对游戏数据产生影响
作者想说的：
今天在B站上看到一些视频，发现很多人喜欢脱离需求谈架构，可能这更多是一种技术不成熟或者不负责任的体现。
架构是技巧，是工具，脱离需求谈工具恐怕只能是百害而无一益。
很多时候所谓的程序架构并没有想象中那么复杂，我们在谈论架构的时候切记不能脱离需求，否则不仅不能解决问题，还会陷入过度设计的漩涡，造成系统冗杂无法推进。
