一、微服务
1.1 什么是微服务
微服务就是一些协同工作的小而自治的服务。
关键词： 小而自治
-- 小
“小”这个概念，一方面体现在微服务的内聚性上。
- 内聚性也可以称之为单一职责原则：“把因相同原因而变化的东西聚合到一起，而把因不同原因而变化的东西分离开来。”
- 也就是说，微服务应该专注于做好一件事情。
- 由业务边界来确定服务的边界
-- 自治
“自治”这个概念，强调的是，一个微服务就是一个独立的实体。体现在服务之间的松耦合上。黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？
1.2 微服务的好处
-
技术异构性
- 不同服务根据业务场景、性能要求、功能需求采用不同的技术架构
- 新技术的快速实践，技术团队的快速成长
-
弹性/反脆弱性（anti-fragility）
- 服务降级
- 服务容灾、服务熔断
-
扩展
- 传统单体系统，无法做到对局部功能进行扩展
- 根据具体的业务需求，对特定的微服务进行扩展
- 通过架构的手段，节省成本
-
简化部署
- 传统单体应用，即使是一行代码修改，也需要整体重新部署。风险太大。
- 微服务架构，各个服务部署相互独立
- 灵活的发版方式
- 快速回滚
- 风险小
-
架构与组织结构相匹配
- 关联知识点：康威定律
- 服务的可重用、可组合
- 服务的可替代性，快速重写
1. 3微服务的弊端
对运维能力要求高；运行效率会降低；技术要求高，需要处理事务最终一致性等问题。微服务不该是这样的：
二、好服务的特征
2.1松耦合
松耦合指的是，修改一个服务，而另一个相关的服务，不需要修改。微服务的重要特点就是：能够独立修改和部署单个服务，而不会影响、甚至修改系统中的其它服务。
一个服务应该尽可能少地了解与之协作的服务信息。因为过度了解，会导致紧耦合。
2.2高内聚
高内聚指的是，把相关的行为聚集在一起。这样，需要改变行为时，只需要在一处修改，然后独立发布。
我们需要做的是，找出业务领域的边界，然后实现高内聚
三、微服务拆分原则
还是要重申两个重要概念，高内聚和松耦合，对应前面的关键词：小而自治。
3.1限界上下文
微服务一定要有清晰的功能边界。一个微服务对应了一个功能集合，这些功能一定是有一些共性的。比如，订单服务，那么创建订单、修改订单、查询订单列表，一般是订单服务的功能集合。
3.2逐步划分
一开始，我们会首先识别出一个粒度比较粗的服务模型。领域拆分并不是一步到位的，应当根据实际情况逐步展开。从单体应用到微服务体系的拆分过程能很好的说明这个问题。所以如果一开始不知道应该划分多细，完全可以先粗粒度划分，然后随着需要，初步拆分。比如一个电商一开始索性可以拆分为商品服务和交易服务，一个负责展示商品，一个负责购买支付。随后随着交易服务越来越复杂，就可以逐步的拆分成订单服务和支付服务。
四、DDD领域驱动设计
DDD 是一种架构设计方法，微服务是一种架构风格，DDD可以看作是微服务的方法论。两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。
- DDD是一个很好的应用于微服务架构的方法论;
- 在项目的全生命周期内，所有岗位的人员都基于对业务的相同的理解来开展工作。所有人员站在用户的角度、业务的角度去思考问题，而不是站在技术的角度去思考问题;
- 诞生于2004年，兴起于2014年（微服务元年）;
- DDD晦涩难懂，难以落地。因为DDD是方法论，不是行动指南
4.1 领域和子域
领域可以是多个子领域的一个虚拟集合，换句话说多个微服务也可以形成一个大域，不必纠结于领域和微服务之间的数量对应关系。例如在做架构设计的时候可能就把订单域作为一个领域，代表了这个域就是关于订单的，具体该有几个微服务，这需要更细的详细设计来提供。子域可以根据自身重要性和功能属性划分为三类子域，它们分别是：核心域、通用域和支撑域
4.2 界限上下文
任何领域模型都必须是在其特定的上下文环境中，如果DDD超出了其界定的上下文，则会产生歧义或者错误。例如社交媒体中的连接和网络应用中的连接的含义是完全不同的。对于任何上下文，我们都必须要能够建立明确的上下文的关联关系和边界。模型中的角色和边界的定义，在项目中非常重要。
4.3 库
库（Repositories）库指的是所有拥有共同实体和值接口的服务，且这些实体和值都在同一个聚合组中。库通常应该有增加，删除，修改和查找组中对象的方法。可以直接通过应用业务逻辑查询的引用来进行简洁的查询。
4.4 通用语言
通用语言就是能够简单、清晰、准确描述业务涵义和规则的语言。通用语言是团队统一的语言，不管你在团队中承担什么角色，在同一个领域的软件生命周期里都使用统一的语言进行交流。那么，通用语言的价值也就很明了，它可以解决交流障碍这个问题
4.5 聚合和聚合根
聚合(Aggregate)：用来定义领域对象所有权和边界的领域模式，是用来帮助简化模型对象间的关系。通过定义对象之间清晰的所属关系和边界来实现领域模型的内聚，并避免了错综复杂的难以维护的对象关系网的形成。
聚合根(Aggregate Root)：每个聚合都有一个根对象(聚合根实体)，从外部访问只能通过这个对象。根实体对象有组成聚合所有对象的引用，但是外部对象只能引用根对象实体。只有聚合根才能使用仓储库直接查询，如果根实体被删除，聚合内部的其它对象也将被删除。
4.6 实体和值对象
实体(Entity)：一个由它的标识定义的对象叫做实体。通常实体具备唯一ID，能够被持久化，具有业务逻辑，对应现实世界业务对象。
值对象(Value Object)：一个没有概念上标识符描述一个领域方面的对象，这些对象是用来表示临时的事物，或者可以认为值对象是实体的属性，这些属性没有特性标识但同时表达了领域中某类含义的概念。通常值对象不具有唯一ID，由对象的属性描述，可以用来传递参数或对实体进行补充描述。
4.7 领域事件
领域事件是对领域内发生的活动进行的建模。一个消息监听可以当成一个领域事件，表示发生了什么事情，然后需要做什么。领域事件对象用于记录模型产生的离散事件，我们必须谨慎选择和记录领域事件，仅仅对于那些有意义的事件进行记录。
4.8 领域和数据库
一般按垂直业务拆分，一个服务对应独立的库（也可能出现多个服务公用一个库，从设计上通常没有公用表），绝大多数情况下，一个服务和一个数据库搭配，对外提供接口。数据库应该被视为每个领域服务层微服务的私有数据库。
4.9 领域内拆分
领域拆分并不是一成不变的，应当具体情况具体分析。比如大众点评，其订单服务就拆分为了order-service和order-query-service，一来为了读写分离，二来order-query-service作为单独应用可以按需水平扩容。
4.10 核心子域、支撑子域、通用子域
-- 核心子域：
决定业务成功和公司核心竞争力的子域，整个系统最重要部分。 Eric Evans 曾提出如下问题助识别核心域：
- 为何这系统值得写？
- 为何不直接买个？
- 为何不让外包写？
若你对这几个问题的回答能帮你找到这个系统非写不可的理由，则它就是核心域。如电商系统的订单、商品服务。
-- 支撑子域（Supporting Subdomain）
不是你的核心竞争力，但又得做，市场无现成方案的子域。既不包含决定产品和公司核心竞争力的功能，也不包含通用功能的子域，但又必需。
具有企业特性，但不具通用性，如：
- 数据代码类的数据字典等系统
- 排行榜，可能根据各种信息排名，这种东西没人会按你需要做个，但对你自己，又是扩展自己系统的重要举措
- 调用银联、支付宝等第三方支付，即下游
- 报表系统
- 监控系统
-- 通用域（Generic Subdomain）
无太多个性化需求，同时会被多个子域使用的通用功能子域。如认证、权限等，无企业特点限制，无需太多定制化。行业里都这么做，即便不自己做，也不影响业务运行。
如很多 App 要给用户发通知，这种功能完全可买个服务，丝毫不影响业务运行。
五、DDD领域驱动经典四层设计
脚本式编程（dao+service）与DDD领域驱动模式区别如下：
5.1展现（表现层/用户接口层）（Presentation Layer）：
负责以Restful的格式接受Web请求，然后将请求路由给Application层执行，并返回视图模型（View Model），其载体通常是DTO（Data Transfer Object）；
5.2应用层（Application Layer）：
主要负责获取输入，组装上下文，做输入校验，调用领域层做业务处理，如果需要的话，发送消息通知。当然，层次是开放的，若有需要，应用层也可以直接访问基础实施层；应用层连接用户接口层和领域层，不应该实现领域模型的核心领域逻辑。主要职能：协调领域层多个聚合完成服务的组合和编排。应用服务主要负责服务组合、编排和转发，处理业务用例的执行顺序以及结果的拼装。在应用服务中还可以进行安全认证、权限校验、事务控制、领域事件发布或订阅等。
5.3领域层（Domain Layer）：
领域层是领域模型的核心，主要实现领域模型的核心业务逻辑。领域模型的业务逻辑主要由实体和领域服务来实现。其中实体会采用充血模型来实现业务功能，如单一实体（或值对象）不能实现时，就交由领域服务进行组合和协调聚合内多个实体（或值对象），实现复杂的业务逻辑。
主要是封装了核心业务逻辑，并通过领域服务（Domain Service）和领域对象（Entities）的函数对外部提供业务逻辑的计算和处理；
5.4基础实施层（Infrastructure Layer）：
主要包含Tunnel（数据通道）、防腐层，Config和Common。这里我们使用Tunnel这个概念来对所有的数据来源进行抽象，这些数据来源可以是数据库（MySQL，NoSql）、搜索引擎、文件系统、也可以是SOA服务等；Config负责应用的配置；Common是通用的工具类。
基础层贯穿DDD所有层。其职能：提供通用的技术和基础服务，包括第三方工具、驱动、消息中间件、网关、文件、缓存以及数据库等。
六、如何进行DDD领域驱动设计
DDD 包括战略设计和战术设计两部分，它们分别从不同的视角出发，完成领域建模和微服务的拆分和设计。事件风暴(Event Storming)是落实领域驱动的一种常用方法，使用事件风暴能够通过领域事件来识别出聚合根，组合的聚合根则又组成限界上下文，限界上下文则正是我们寻找的“微服务”的概念。
6.1战略设计
是从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界。以一种领域专家、设计人员、开发人员都能理解的“通用语言”作为相互交流的工具，在不断交流的过程中发现和挖出一些主要的领域概念，然后将这些概念设计成一个领域模型；
6.2战术设计
则是从技术视角出发，侧重于对领域模型的技术实现，按照领域模型完成微服务的开发和落地。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中完成设计和系统落地。 由领域模型驱动软件设计，用代码来表现该领域模型。领域需求的最初细节，在功能层面通过领域专家的讨论得出。
七、领域模型建模
UML建模示例：
@startuml
hide circle
note "知识库领域建模" as knowledge_uml #yellow
entity 知识库 {
kie_knowledge
==
知识来源：工单、设备
类型: 知识、案例
知识状态: 待提交、已发布、已撤销
查看次数：调用详情次数
}
entity 知识操作日志 {
kie_knowledge_operation_log
==
操作名称
知识ID
操作人ID
操作人名字
是否成功（success）
操作类型: 存入草稿，撤销，发布
}
entity 知识关联对象 {
kie_knowledge_linked_object
==
知识ID
对象上下文快照: jsonb
}
entity 知识点赞记录 {
kie_knowledge_like_record
==
用户ID
知识ID
点赞标识：bool
}
知识库 ||--|{ 知识操作日志
知识库 ||--o{ 知识关联对象
知识库 ||--o{ 知识点赞记录
@enduml
文章来源：https://www.toymoban.com/news/detail-439342.html
文章来源地址https://www.toymoban.com/news/detail-439342.html
到了这里，关于微服务和领域驱动的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
