关键词：
上篇我们聊了微服务的DDD之间的关系，很多人还是觉得很虚幻，DDD那么复杂的理论，聚合根、值对象、事件溯源，到底我们该怎么入手呢？
实际上DDD和面向对象设计、设计模式等等理论有千丝万缕的联系，如果不熟悉OOA、OOD，DDD也是使用不好的。不过学习这些OO理论的时候，大家往往感觉到无用武之地，因为大部分的Java程序员开发生涯是从学习J2EE经典的分层理论开始的（Action、Service、Dao），在这种分层理论中，我们基本没有啥机会使用那些所谓的“行为型”的设计模式，这里的核心原因，就是J2EE经典分层的开发方式是“贫血模型”。
Martin Fowler在他的《企业应用架构模式》这本书中提出了两种开发方式“事务脚本”和“领域模型”，这两种开发分别对应了“贫血模型”和“充血模型”。
事务脚本开发模式
- 事务脚本的核心是过程，可以认为大部分的业务处理都是一条条的SQL，事务脚本把单个SQL组织成为一段业务逻辑，在逻辑执行的时候，使用事务来保证逻辑的ACID。最典型的就是存储过程。当然我们在平时J2EE经典分层架构中，经常在Service层使用事务脚本。
使用这种开发方式，对象只用于在各层之间传输数据用，这里的对象就是“贫血模型”，只有数据字段和Get/Set方法，没有逻辑在对象中。
我们以一个库存扣减的场景来举例：
- 业务场景
首先谈一下业务场景，一个下订单扣减库存（锁库存），这个很简单
先判断库存是否足够，然后扣减可销售库存，增加订单占用库存，然后再记录一个库存变动记录日志（作为凭证） - 贫血模型的设计
首先设计一个库存表 Stock，有如下字段
设计一个Stock对象(Getter和Setter省略)
public class Stock
private String spuId;
private String skuId;
private int stockNum;
private int orderStockNum;
- Service入口
设计一个StockService，在其中的lock方法中写逻辑
入参为(spuId, skuId, num)
实现伪代码
count = select stocknum from stock where spuId=xx and skuid=xx
if count>num
update stock set stocknum=stocknum-num, orderstocknum=orderstocknum+num where skuId=xx and spuId=xx
else
//库存不足，扣减失败
insert stock_log set xx=xx, date= new Date()
-
ok，打完收工，如果做的好一些，可以把update和select count合一，这样可以利用一条语句完成自旋，解决并发问题（高手）。
小结一下：
有没有发现，在这个业务领域非常重要的核心逻辑 -- 下订单扣减库存中操作过程中，Stock对象根本不用出现，全部是数据库操作SQL，所谓的业务逻辑就是由多条SQL构成。Stock只是CRUD的数据对象而已，没逻辑可言。 -
马丁福勒定义的“贫血模型”是反模式，面对简单的小系统用事务脚本方式开发没问题，业务逻辑复杂了，业务逻辑、各种状态散布在大量的函数中，维护扩展的成本一下子就上来，贫血模型没有实施微服务的基础。
-
虽然我们用Java这样的面向对象语言来开发，但是其实和过程型语言是一样的，所以很多情况下大家用数据库的存储过程来替代Java写逻辑反而效果会更好，（ps：用了Spring boot也不是微服务），
领域模型的开发模式
- 领域模型是将数据和行为封装在一起，并与现实世界的业务对象相映射。各类具备明确的职责划分，使得逻辑分散到合适对象中。这样的对象就是“充血模型” 。
- 在具体实践中，我们需要明确一个概念，就是领域模型是有状态的，他代表一个实际存在的事物。还是接着上面的例子，我们设计Stock对象需要代表一种商品的实际库存，并在这个对象上面加上业务逻辑的方法
这样做下单锁库存业务逻辑的时候，每次必须先从Repository根据主键load还原Inventory这个对象，然后执行对应的lock(num)方法改变这个Inventory对象的状态（属性也是状态的一种），然后再通过Repository的save方法把这个对象持久化到存储去。
完成上述一系列操作的是Application,Application对外提供了这种集成操作的接口
领域模型开发方法最重要的是把扣减造成的状态变化的细节放到了Inventory对象执行，这就是对业务逻辑的封装。
Application对象的lock方法可以和事务脚本方法的StockService的lock来做个对比，StockService是完全掌握所有细节，一旦有了变化（比如库存为0也可以扣减），Service方法要跟着变；而Application这种方式不需要变化，只要在Inventory对象内部计算就可以了。代码放到了合适的地方，计算在合适层次，一切都很合理。这种设计可以充分利用各种OOD、OOP的理论把业务逻辑实现的很漂亮。
- 充血模型的缺点
从上面的例子，在Repository的load 到执行业务方法，再到save回去，这是需要耗费一定时间的，但是这个过程中如果多个线程同时请求对Inventory库存的锁定，那就会导致状态的不一致，麻烦的是针对库存的并发不仅难处理而且很常见。
贫血模型完全依靠数据库对并发的支撑，实现可以简化很多，但充血模型就得自己实现了，不管是在内存中通过锁对象，还是使用Redis的远程锁机制，都比贫血模型复杂而且可靠性下降，这是充血模型带来的挑战。更好的办法是可以通过事件驱动的架构来取消并发。
领域模型和微服务的关系
上面讲了领域模型的实现，但是他和微服务是什么关系呢？在实践中，这个Inventory是一个限界上下文的聚合根，我们可以认为一个限界上下文是一个微服务进程。
不过问题又来了，一个库存的Inventory一定和商品信息是有关联的，仅仅靠Inventory中的冗余那点商品ID是不够的，商品的上下架状态等等都是业务逻辑需要的，那不是又把商品Sku这样的重型对象引入了这个微服务？两个重型的对象在一个服务中？这样的微服务拆不开啊，还是必须依靠商品库？！
原文 曹祖鹏
多研究些架构，少谈些框架
论微服务架构的核心概念微服务架构和SOA区别微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA... 查看详情
多研究些架构，少谈些框架——一名阿里架构师的笔记
微服务架构和SOA区别微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么... 查看详情
从经典架构项目中透析微服务架构的核心概念和充血模型
微服务架构和SOA区别微服务现在辣么火，业界流行的对比的却都是所谓的Monolithic单体应用，而大量的系统在十几年前都是已经是分布式系统了，那么微服务作为新的理念和原来的分布式系统，或者说SOA（面向服务架构）是什么... 查看详情
做好架构师，要懂微服务，汇总微服务架构落地的15种框架(转)
...家企业里，30%在使用微服务，15%在实验开发和测试微服务架构，24%在学习微服务准备转型，只有剩下的30%的企业没有使用微服务。微服务到底有什么好呢？微服务在2013年才被提出，短短几年就有这么快速的发展。微服务架构能... 查看详情
领域驱动设计系列贫血模型和充血模型(代码片段)
面向过程的设计方式（贫血模型）假设现在有一个银行支付系统项目，其中的一个重要的业务用例是账户转账业务。系统使用迭代的方式进行开发，在1.0版本中，该用例的功能需求非常简单，事件流描述如下：主事件流：用户登... 查看详情
贫血模型和充血模型
...象被称为"贫血对象"(VO)，而只有"行为"的对象一般被用作服务对象，就像spring的server一样，都是无状态对象，本身并不存储数据，只处理逻辑。充血模型：业务逻辑和持久化都放在对象中，BusinessLogic（业务逻辑层）只负责简单封... 查看详情
微服务架构引入的问题及解决方案
微服务间如何通讯？从通讯模式角度考虑一对一还是一对多？一对一同步：请求响应模式，最常见异步：通知/请求异步响应一对多异步：发布订阅/发布异步响应从通讯协议角度考虑RESTAPIRPCMQ如何选择RPC框架I/O、线程调度模型序... 查看详情
springcloud都做了些什么
...用。本次分享主要解答这两个问题：SpringCloud在微服务的架构中都做了哪些事情？SpringCloud提供的这些功能对微服务的架构提供了怎样的便利？ 我们先来简单回顾一下，我们以往互联网架构的发展情况： 传统架构发展史... 查看详情
什么是微服务架构？主流的微服务如何实现？
简单地说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，并且使用轻量级，通用的机制在这组应用间进行通信。主流的微服务包括：1... 查看详情
用友云服务治理平台助力企业微服务架构落地
本文主要阐述使用微服务架构时，治理框架或者平台需要解决的主要问题，微服务落地实施过程中所遇到的关键问题和对应解决方案。同时，文章也介绍用友云旗下的微服务治理平台的核心功能和技术架构，以及微服务治理平台... 查看详情
谈微服务架构（转）
...特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的，对于微服务架构，既然出现了这个新名称， 查看详情
微服务系列1：服务化框架落地的挑战和核心需求
一、微服务架构概览1-1、微服务出现的意义所在微服务出现的意义在哪里呢？它的优势有哪些呢？如何保障业务演进但是系统架构还是依然往好的方向发展呢？一般而言，随着公司产品线的不断扩大，业务系统会越来越多，功能... 查看详情
（转）如何保障微服务架构下的数据一致性？
...oud.tencent.com/developer/article/1459734【1】写在前面随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独... 查看详情
[转]微服务架构
...转自：https://www.cnblogs.com/imyalost/p/6792724.html资料来源：有架构给我的一些资料，以及自己百度和论坛、社区找来的一些资料，权当做一个总结式的简介。。。 目录如下：一、微服务架构介绍二、出现和发展三、传统开发模式... 查看详情
re：从0开始的微服务架构--如何保障微服务架构下的数据一致性--转
...文地址：http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg随着微服务架构的推广，越来越多的公司采用微服务架构来构建自己的业务平台。就像前边的文章说的，微服务架构为业务开发带来了诸多好处的同时，例如单一职责、独立开发部署... 查看详情
icml2022｜达摩院多模态模型ofa，实现模态任务和架构三个统一
...f1a;霜清、钟煌、鸿侠通用统一的预训练大模型逐渐成为AI研究的一大趋势，本文将介绍达摩院提出的多模态模型OFA，是如何实现架构、模态、任务的三个统一。近年来，基于大规模无监督数据的预训练逐渐成为深度学... 查看详情
ddd（领域驱动设计）分享（1/2）
...的概念模式，解决特定领域的问题相比于传统的三层架构来说，**DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面 查看详情
架构实践架构扩展立方体scalecube是一个用于细分服务定义微服务和扩展产品的模型
目录The ScaleCube 架构扩展立方体3DIMENSIONSOFSCALING 缩放的3个维度 查看详情