基本概念
- 康威定律
- 第一定律
- Communication dictates the design.
- 组织沟通方式会通过系统设计表达出来
- 对于复杂的，需要协作完成的系统开发，沟通是必须要持续提升的问题。
- 每个团队由5-10人组成（
沟通成本 = n(n-1)/2），在团队内部进行频繁的、细粒度的沟通。对于团队外部，定义好接口，契约，只进行粗粒度的沟通。这样可以降低沟通成本，同时也符合高内聚，低耦合原则（代码和人员管理有些时候真是相通的）。
- Communication dictates the design.
- 第二定律
- There is never enough time to do something right, but there is always enough time to do it over.
- 时间再多一件事情也不可能做的完美，但总有时间做完一件事情
- 这就是我们在用 kanban 管理迭代时几乎都有一列是 BAU（Business As Usual），其中会包括一些日常修复的 Bug Story。敏捷开发中将迭代引入，做到持续交付，快速验证，迅速反馈，持续改进。
- There is never enough time to do something right, but there is always enough time to do it over.
- 第三定律
- There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
- 线型系统和线型组织架构间有潜在的异质同态特性
- 大白话就是，你想要架构成为什么样，就将团队分成怎样的结构。比如前后端分离的团队，架构就是基于前后端分离。在基于微服务设计的团队里，一个很好的理念是自管理。团队内部对于自己所负责的模块高度负责，进行端对端的开发以及运维。
- There is a homomorphism from the linear graph of a system to the linear graph of its design organization.
- 第四定律
- The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.
- 大的系统组织总是比小系统更倾向于分解
- 合久必分，分久必合，团队以及架构都是在不断优化的。一个团队随着人员的增加，沟通以及管理成本一定会增加。
- The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems.
- 第一定律
项目架构
- 单机架构
- 特征是整个开发围绕着数据库进行设计和开发。
- 存在的问题
- 系统复杂：内部多个模块紧耦合，关联依赖复杂，牵一发而动全身。
- 运维困难：变更或升级的影响分析困难，任何一个小修改都可能导致单体应用整体运行出现故障。
- 无法扩展：无法拆分部署，出现性能瓶颈后往往只能够增加服务器或增加集群节点，但是 DB 问题难解决
- 三层式的集中式架构
- 采用面向对象的设计方法，业务逻辑分业务层、逻辑层、数据访问层，这种架构很容易某一层或者几层变得臃肿，扩展性较差， 另外摩尔定律失效， 单台机器性能有限。
- SOA
- 提出 MicroService 概念的 Martin Fowler 说过，“我们应该把 SOA 看作微服务的超集”，也就是说微服务是 SOA 的子集。
- SOA 的探索大概始于 2000 年（概念产生可能更早一些），大家知道当初 ERP、CRM、OA 之类的信息系统都是一套套部署起来的，不同系统往往由不同的供应商分别开发的，技术差别也很大，各个系统孤零零的，企业于是有了应用集成和数据集成的需求，SOA 就出来了，各个系统对外提供粗粒度的服务供外部系统访问，所有的服务都集中在一个 ESB 上，曾经 SOA 和 SOA 治理是信息化领域的热门话题，然而这种集成方式开发代价大、通信效率低，且有单点故障的风险， 实际上在企业中并没有得到大规模应用。
- ESB
- ESB 就是一根管道，用来连接各个服务节点。ESB的存在是为了集成基于不同协议的不同服务，ESB 做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。
- 从名称就能知道，它的概念借鉴了计算机组成原理中的通信模型——总线，所有需要和外部系统通信的系统，统统接入 ESB，岂不是完美地兼容了现有的互相隔离的异构系统，可以利用现有的系统构建一个全新的松耦合的异构的分布式系统。
- 相关问题
- SOA、ESB、微服务的区别和关系
- SOA 是一种理念，它的主要特性–面向服务的分布式计算，服务间松散耦合，支持服务的封装，服务注册和自动发现，以服务契约方式定义服务交互方式。但是，SOA 并没有定义出具体的实现方式，目前有两套 SOA 理念的实现方式：中心化和去中心化，这两套架构并没有优劣之分，还是要针对企业的根本诉求。
- SOA 中心化的实现方式就是 ESB，ESB 的根本诉求是为了解决异构系统之间的连通性，通过协议转换、消息解析、消息路由把服务提供者的数据传送到服务消费者。所以，ESB 是中心化的，很重，有一定的逻辑，但它的确可以解决一些公用逻辑的问题。
- SOA 去中心化的实现方式的根本诉求是扩展性，实现方式就是微服务。
- SOA、ESB、微服务的区别和关系
- 微服务
- 实现应用之间的解耦，解决单体应用扩展性的问题。
- 微服务存在的问题
- 业务或者微服务的边界界定
- 业务划分方式
- 领域驱动建模（DDD）
- DDD 不是一种架构，而是一种架构方法论，目的就是将复杂问题领域简单化，帮助我们设计出清晰的领域和边界，可以很好的实现技术架构的演进。
- 战略设计、战术设计
- 战略设计
- 在某个领域，核心围绕上下文的设计
- 主要关注上下文的划分、上下文映射的设计、通用语言的定义
- 问题空间、解决空间
- 战术设计
- 核心关注上下文中的实体建模，定义值对象、实体等，更偏向开发细节
- 战术设计的术语
- 实体
- 实体是指描述了领域中唯一的且可持续变化的抽象模型，通常建模时，名词用于给概念命名，形容词用于描述这些概念，而动词则表示可以完成的操作
- 值对象
- 描述了领域中的一件东西，将不同的相关属性组合成了一个概念整体，当度量和描述改变时，可以用另外一个值对象予以替换，属性判等、固定不变
- 服务
- 标识的是在领域对象之外的操作与行为，接受用户的请求和执行某些操作
- 聚合
- 实体和值对象会形成聚合，每个聚合一般是在一个事物中操作，一般都有持久化操作。聚合中，根实体的生命周期决定了聚合整体的生命周期
- 工厂（Facotry）和仓库（Repository）
- 实体
- 战略设计
- 领域服务、应用服务、实体行为
- 职能、原则
- 应用服务
- 编排领域服务
- 暴露系统的全部功能
- 安全验证、持久化处理
- 轻量级、不处理业务逻辑
- 跨模块协调
- DTO 转换、AOP、邮件短信、消息通知
- 实体行为
- 体现实体业务行为
- 根实体：公开接口行为、保证不变条件
- 负责协调实体和值对象按照完成业务逻辑
- 领域服务
- 组织业务逻辑（流程、策略、规则、完整性约束等）
- 协调方案、非必要性
- 协调领域对象的行为、无状态
- 某个动作不适合放在聚合对象上时
- 过度使用领域服务将导致贫血模型
- 应用服务
- 职能、原则
- 特点
- 领域模型是对具有某个边界的领域的一个抽象，反映了领域内用户业务需求的本质；领域模型是有边界的，只反应了我们在领域内所关注的部分；
- 领域模型只反映业务，和任何技术实现无关；领域模型不仅能反映领域中的一些实体概念，如货物，书本，应聘记录，地址，等；还能反映领域中的一些过程概念，如资金转账，等；
- 领域模型确保了我们的软件的业务逻辑都在一个模型中，都在一个地方；这样对提高软件的可维护性，业务可理解性以及可重用性方面都有很好的帮助；
- 领域模型能够帮助开发人员相对平滑地将领域知识转化为软件构造；
- 领域模型贯穿软件分析、设计，以及开发的整个过程；领域专家、设计人员、开发人员通过领域模型进行交流，彼此共享知识与信息；因为大家面向的都是同一个模型，所以可以防止需求走样，可以让软件设计开发人员做出来的软件真正满足需求；
- 要建立正确的领域模型并不简单，需要领域专家、设计、开发人员积极沟通共同努力，然后才能使大家对领域的认识不断深入，从而不断细化和完善领域模型；
- 为了让领域模型看的见，我们需要用一些方法来表示它；图是表达领域模型最常用的方式，但不是唯一的表达方式，代码或文字描述也能表达领域模型；
- 领域模型是整个软件的核心，是软件中最有价值和最具竞争力的部分；设计足够精良且符合业务需求的领域模型能够更快速的响应需求变化；
- 可以通过三步来确定领域模型和微服务边界
- 在事件风暴中梳理业务过程中的用户操作、事件以及外部依赖关系等，根据这些要素梳理出领域实体等领域对象。
- 根据领域实体之间的业务关联性，将业务紧密相关的实体进行组合形成聚合，同时确定聚合中的聚合根、值对象和实体。在这个图里，聚合之间的边界是第一层边界，它们在同一个微服务实例中运行，这个边界是逻辑边界，所以用虚线表示。
- 根据业务及语义边界等因素，将一个或者多个聚合划定在一个限界上下文内，形成领域模型。在这个图里，限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界，不同限界上下文内的领域逻辑被隔离在不同的微服务实例中运行，物理上相互隔离，所以是物理边界，边界之间用实线来表示。
- 领域驱动建模（DDD）
- IaaS
- 基础设施即服务（IaaS：Infrastructure as a Service）
- 把计算基础（服务器、网络技术、存储和数据中心空间）作为一项服务提供给客户。它也包括提供操作系统和虚拟化技术、来管理资源。消费者通过 Internet 可以从完善的计算机基础设施获得服务。
- 优点：相对其他几种服务，它的自由度、灵活度非常的高。客户可以自行安装自己喜欢的操作系统、方便自己的数据集、需要的软件等。所以，一切东西可以自行部署。我的理解是有点像学生时代去机房上网。
- 缺点：它的维护成本比较高。使用它会导致 CPU、内存等等计算资源浪费。相关的人力资源和时间资源也会被浪费。相当于把资源分割成一个一个个性化的虚拟的电脑，它们之间互相独立。“土地”就只有这么多，分完了就没有了。而对于用户来说，必须要自行下载操作系统等等繁琐的操作。对于云端和用户来说，各种资源其实都浪费了。
- Paas
- 平台即服务（PaaS：Platform as a Service）
- PaaS 实际上是指将软件研发的平台作为一种服务，供应商提供超过基础设施的服务，一个作为软件开发和运行环境的整套解决方案，即以 SaaS 的模式提交给用户。因此，PaaS 也是 SaaS 模式的一种应用。但是，PaaS 的出现可以加快 SaaS 的发展，尤其是加快 SaaS 应用的开发速度。
- 优点：减少的搭建各种平台的损耗，为云端和用户节省了资源。
- 缺点：相对 IaaS 来说，PaaS 的自由度和灵活度比较低，不太适合专业性比较高的 IT 技术从业人员。相当于范围被限定，在特定的范围做一些事情。我的理解有点像 QQ 远程控制自己的电脑处理事情。
- Saas
- 大数据的特征（4V 特征）
- 规模性（Volume）
- 随着信息化技术的高速发展，数据开始爆发性增长。大数据中的数据不再以几个 GB 或几个 TB 为单位来衡量，而是以 PB（1千个T）、EB（1百万个T）或 ZB（10亿个T）为计量单位。
- 高速性（Velocity）
- 这是大数据区分于传统数据挖掘最显著的特征。大数据与海量数据的重要区别在两方面：一方面，大数据的数据规模更大；另一方面，大数据对处理数据的响应速度有更严格的要求。实时分析而非批量分析，数据输入、处理与丢弃立刻见效，几乎无延迟。数据的增长速度和处理速度是大数据高速性的重要体现。
- 多样性（Variety）
- 多样性主要体现在数据来源多、数据类型多和数据之间关联性强这三个方面。
- 价值性（Value）
- 尽管企业拥有大量数据，但是发挥价值的仅是其中非常小的部分。大数据背后潜藏的价值巨大。由于大数据中有价值的数据所占比例很小，而大数据真正的价值体现在从大量不相关的各种类型的数据中。挖掘出对未来趋势与模式预测分析有价值的数据，并通过机器学习方法、人工智能方法或数据挖掘方法深度分析，并运用于农业、金融、医疗等各个领域，以期创造更大的价值。
- 规模性（Volume）
