项目架构
前言
FireTeam目前项目均采用SpringBoot、Dubbo等技术框架以及DDD(Domain Driver Design)设计思想搭建。书写这篇文档一方面是帮助新加入的小伙伴更快地熟悉项目，另一方面是形成团队规范、保持代码风格统一，接下来讲主要通过以下几个方面进行介绍：

名词与概念
目录结构
项目模块
设计理念

文献

领域驱动设计DDD和CQRS落地

项目架构分析

1.1-什么是架构
1.2-从系统层次进行架构分析 
1.2.1-iOS系统框架介绍
1.2.2-软件架构分析
1.3-从应用层次进行架构分析
1.1-什么是架构？

我们人类在做事之前喜欢先把它的整体结构设想一下，就像盖一座大厦，可能会想用砖盖，还是用最新的环保隔声材料盖，里面的格局是采用中式的还是欧式的，彩色主色采用什么等等，这些相关的数据都需要提前规定好，事实上项目架构也是这样
在一个好的架构下编程，不仅对于开发人员是一件赏心悦目的事情，更重要的是软件能够表现出一个健康的姿态；而架构设计的不合理，不仅对于开发人员是一件受苦受难的事情，软件本身的质量更是受到严重威胁。
1.2-从系统层次进行架构分析



1.2.1-iOS系统架构介绍

我们在开发中去架构一款软件，很大程度上我们参考了iOS系统自身的架构，这样获取更加具有说服力
iOS的系统架构分为四个层次：核心操作系统层（Core OS layer）、核心服务层（Core Services layer）、媒体层（Media layer）和可触摸层（Cocoa Touch layer）

Core OS是位于iOS系统架构最下面的一层是核心操作系统层，它包括内存管理、文件系统、电源管理以及一些其他的操作系统任务。它可以直接和硬件设备进行交互。作为app开发者不需要与这一层打交道
Core Services是核心服务层，可以通过它来访问iOS的一些服务
Media是媒体层，通过它我们可以在应用程序中使用各种媒体文件，进行音频与视频的录制，图形的绘制，以及制作基础的动画效果
Cocoa Touch是可触摸层，这一层为我们的应用程序开发提供了各种有用的框架，并且大部分与用户界面有关，本质上来说它负责用户在iOS设备上的触摸交互操作




1.2.2-软件架构分析

每个人对软件的架构分析是不一样的，在不影响具体开发的情况下，没有人能说自己的架构是好的，别人的架构就一定是不好的，以下只是本人多年开发经验积累的一些感悟，仅供参考

衡量一个软件架构的好坏，最有说服力的就是它的存活性，即能够在原有的架构师迭代几个版本，维护多少年~
软件标准的四层架构如下

1.展示层：负责系统与客户的交互 
我们的MVC属于展示层
2.业务逻辑层：负责处理系统的业务逻辑 
主要是将应用的核心业务进行分离封装，复用性很高
3.数据访问层：负责处理数据，与不同的数据打交道 
如我们软件开发中的单例模式
如开发中对AFN框架的二次封装（单例模式实现AFNetworkingManager）
4.服务层：负责与其他系统进行数据交互和业务集成 
如开发中的网络层：负责我们软件与后台之间的数据交互
如开发中的硬件层：负责与硬件设备交互（硬件都是二进制，需要底层封装）


1.3-从应用层次进行架构分析

有了系统层次的分析，我们需要将系统层次的架构具体的反应到我们的工程中，并且针对应用开发来搭建我们工程的目录结构
1.模块划分   

分析项目需求，进行模块划分 
MVC或者MVVM或者MVP
2.通用组件 
1.通用宏
2.通用工具 
自定义类
系统分类
3.通用UI
3.核心服务层 
网络层
硬件层
4.通用模型 
跨模块数据层
5.第三方框架
6.应用资源 
音频、视频

分布式项目架构

根据业务需求进行拆分成N个子系统，多个子系统相互协作才能完成业务流程子系统之间通讯使用RPC远程通讯技术。

优点:

1.把模块拆分，使用接口通信，降低模块之间的耦合度。

2.把项目拆分成若干个子项目，不同的团队负责不同的子项目。

3.增加功能时只需要再增加一个子项目，调用其它系统的接口就可以。

4.可以灵活的进行分布式部署。

有优点就有缺点，缺点如下：

1.系统之间交互需要使用远程通信，接口开发增加工作量。

2.各个模块有一些通用的业务逻辑无法共用。

为了解决上面分布式架构的缺点，我们引入了soa架构，SOA：Service Oriented Architecture面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。

 

什么是项目集群

多台服务器部署相同应用构成一个集群

作用：通过负载均衡设备共同对外提供服务

项目架构

前几天刚刚了解了一些iOS项目的架构，觉得感慨万分，如果在我的项目成型之前读到这些文章该多好，至少我的项目架构会考虑的更全面一些。 

吃一堑，长一智，所以手头上的vuejs搭建的kd云之家的项目架构要提前考虑好。 

公司没有人搞过vue，前端工程师姐姐也是第一次搞，何况我这个iOS出身的。百度吧，百度不行就谷歌。

搜到一个项目，和一篇文章。项目不错，文章有指导意义，虽然作者很谦虚。。。

看项目最直观的是网络 api 的封装，分两层，网络请求封装为一层（get，post），对外业务层封装为一层
项目不大，其他最重要的倒是对vue的准确适用 
router API 

router API在vue页面中 
route: { 

data(transition) { 

var params = transition.to.params; 

api.cafe.topics(params.slug, params.page, resp => { 

transition.next({ 

  pagination: resp.pagination, 

  topics: resp.data, 

}); 

}); 

} 

}, 



  
在激活阶段被调用，在 activate 被断定（ resolved ，指该函数返回的 promise 被 resolve ）。用于加载和设置当前组件的数据。


  可见对于页面的初始化加载，用这个比用ready，create要正当一些
  
  
 
computed 
computed: { 

  user() { 

  return this.$root.user; 

  }, 

  canWrite() { 

  var permission = this.cafe.permission || {}; 

  return permission.write; 

  }, 

  isAdmin() { 

  var permission = this.cafe.permission || {}; 

  return permission.admin; 

  } 

  }, 

  你应该注意到 Vue.js 的计算属性不是简单的 getter。计算属性持续追踪它的响应依赖。在计算一个计算属性时，Vue.js 更新它的依赖列表并缓存结果，只有当其中一个依赖发生了变化，缓存的结果才无效。因此，只要依赖不发生变化，访问计算属性会直接返回缓存的结果，而不是调用 getter。
可见compute 可以使用缓存机制，对于增加速度是有帮助的。
  
  
组件命名 

  计算科学中最难的两件事是命名和缓存失效。 

  由于vue采用组件化开发，每个组件都是一个文件，文件比较多，所以命名要提现出该控件的通用性。不要觉得命名短才是好，命名应该尽量表达清晰意义。