ddd 领域驱动设计

ddd架构：

团队中包含产品，前端，后端都是一种语言，比如一个概念只有一种叫法，比如空间，不能产品说是空间，开发说是圈子，前端又说是微博；

一个模块中，参数或属性名字应该相同，概念也一致；

出参、入参、中间临时属性统一为领域模型，和业务相关，和数据库无关，也和依赖的基础框架无关；

领域建模中四层架构：

api：对外接口定义，实际上是对Service还做了一层封装，但实际上忽略只做定义；

Service（域模型Domain）包含一个业务或一个领域的所有行为，业务逻辑事件处理在域模型中处理，不对外暴露；

Repository：DB，Redis，以及http，rpc访问外部数据都在该层，这种就算外部数据改变，也不需要改领域内方法，即Service层建模后不因内部数据库变更，不因外部服务改动而修改。虽然合理，但实践中都直接在service层直接调用，特别是rpc，否则就需要中间做一层转换定义边界；

基础设置：DB，Redis，以及http，rpc；

mvc架构：

所有的业务逻辑都在service层中，没有对内外部数据源做一个边界定义。