小结：
1、
微服务中台不是
/1堆砌技术组件就是中台
/2拥有服务治理就是中台
/3增加部分业务功能就是中台
/4Cloud Native 就是中台
https://mp.weixin.qq.com/s/uuaraAWReOYeZuEJiLs9dw
企业微服务中台落地实践和思想之我见
微服务和中台是这几年非常时髦随处可见的词，最先在一批互联网企业中开始谈论和建设，并逐渐的蔓延至一些传统企业和传统的 IT 部门，以至于现在在构建信息系统时，很多企业都在说要建一个中台，但究竟要建成什么样还不是很清楚或者说有些迷茫，笔者在微服务出来的时候也不是特别的明白到底如何建好一个企业中台，只是跟着感觉走，随着主导和经历多个项目后，有了自己的部分认识，可以与大家在此分享。
我们认为中台的意义应该是什么，无论是技术中台，业务中台还是数据中台，我想它应该是为业务和组织而生，为能更加快速敏捷的响应业务的变化，给公司带来效能上的提升，价值上的提升，创新能力的增强，进而还能促进人才和组织的优化，这是中台所存在的意义。
首先在不知道微服务中台是什么样的时候，它一定不是这几个样子：
1. 堆砌技术组件就是中台
只堆技术组件，微服务中台或者说企业中台只包含常用的技术组件，比如使用 spring cloud 微服务框架，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 几个组件之后认为这个就是企业的中台，要什么技术能力拿过去用即可，说法其实并没有错，只是站的角度不同，确实是能力的抽象，封装和开放，但并不是纯粹的堆砌技术组件。
2. 拥有服务治理就是中台
为 spring cloud 这样微服务开发框架增强了服务治理的能力，然后在绑定上业务就是技术中台或者中台。
这样的看法不是完全正确，这只能代表在技术的基础底座和支撑上前进了一步，还远远不够。
3. 增加部分业务功能就是中台
对老系统增加新功能确实是构建中台道路上必须经历的一件事，但如果只是单纯的从增加新功能角度出发而不是为了能力组件化，服务化，封装和开放，协同作战的思想去建设，那么只是给老系统增加负担而不是减负。
4. Cloud Native 就是中台
Cloud Native 是目前比较火的领域，很多企业认为做了微服务，容器，DevOps 就已经构成了中台体系，这也是比较片面的看法，只能说有了这三大块，对于构建中台体系有了一个很好的基座，但真正的中台还并未出现。
@/先从技术中台方面来探讨一下技术中台的落地建设，后续我们再来讨论业务中台。/
刚刚上面我们认为中台应该不是什么样子，那到底中台应该是什么样子，有什么价值，就如我们上面所说，它一定是为业务和组织而生，你可以从很多角度去解读它，本篇文章我们结合在新项目建设中，我们先从技术中台方面来探讨一下技术中台的落地建设，后续我们再来讨论业务中台。
技术中台
如下图，我先把技术中台分为这几部分，当然它包含很大的范围和其他的角度，但我们可以根据这几点展示出部分技术中台思想：
容器平台，虚拟机
微服务框架 (分布式服务框架) && 微服务管理控制台
技术组件
公共基础服务和技术服务
DevOps&&AIOps
效能
容器云，虚拟机
虚拟机和应用上云对 Iaas 厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的 UI 界面，它有助于我们在 Iaas 的配置和运维层面减少工作量，优化人员配置，提高我们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
虚拟机和应用上云对 Iaas 厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的 UI 界面，它有助于我们在 Iaas 的配置和运维层面减少工作量，优化人员配置，提高我们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
对于采用了容器的厂商，起码要在这几方面需要做好，集群的管理和调度，网络方案，服务编排，日志方案，存储方案，应用和服务的管理，容器的监控和告警，镜像仓库的管理，镜像的打包和构建，用户的权限，优秀的 UI 操作界面等等。
同样的对于容器，如果它是一个优秀的产品，那它还应该是这样的：
充分开放的和可扩展的接口。
可以和多个产品进行对应快速，如微服务产品。
丰富和体验方便的 UI， 高度集成功能的 UI，可见即可得。
充分的对接 DevOps 文化，丰富的 CICD 流程，镜像一键打包。
容器应用与非容器应用通信，跨集群通信。
优秀的监控体系。
等等。
这部分的能力是让整个技术中台有一个好的基础设施层支撑，能快速的进行应用的部署和交付，出问题时能迅速定位和恢复，降低 MTTR, 并能充分的利用现有资源进行合理的分配，让技术和业务降低耦合，划分出业务实现者与技术支撑的 BC，关注各自的领域，所以你需要一个非常靠谱和好用的底层支撑。
微服务框架 (分布式服务框架) && 微服务管理控制台
对于传统老应用而言，它可能是传统的单体应用，整个系统的功能都融合在一起。它们在迎接需求剧烈变化和传统开发迭代方面遇到了瓶颈，那么在转型时就会考虑服务化的架构，在做服务化架构时，我们就需要一个完整而健全的分布式服务化框架来帮助我们，诸如 Pivotal 的 Spring Cloud 框架。
但这里要提醒的是，如果你要打造一款真正的技术中台，我认为一个纯粹的 Spring Cloud 的框架是非常不够的，它只能说是一款开发框架，而不是一个真正的微服务产品，不能为业务开发提供充足的保障。那么究竟什么是一款完整的微服务产品呢? 我起码认为它应该拥有这两个基本的能力：
第一，要拥有微服务框架技术能力。
第二，要拥有完整的服务治理能力，拥有应用全生命周期的管理能力。
第一部分是基础的微服务框架能力，这里面应当包括：服务注册，服务发现，负载均衡，熔断保护，服务路由，服务通信等。
第二部分是拥有完整的服务治理能力，这里面的内容比较多，一般会有： 服务的管理，可视化治理界面，服务构建发布，分布式事务，流量控制，监控告警，服务契约，链路跟踪，灰度发布，服务降级等等。
微服务产品这一节可以单独拿出来说，这里就不过多讨论，其实好的产品应该还要有其他部分考量，如对接各种其他技术组件和其他产品的能力。
业界的微服务产品有很多，这里列几款：
腾讯 TSF 产品，Tars 产品。
阿里的 Dubbo, EDAS 系列。
华为的 ServiceComb，ServiceStage 系列。
蚂蚁金服 SOFA 系列。
Pivotal 的 Cloud Foundary。
微软的 Service Fabric。
网易的轻舟微服务。
这部分的内容是我们技术中台的基座，它可以帮我们解决大部分在开发测试，网络通信，分布式等方面的难题，也是我们在构建微服务应用，技术组件，公共支撑等方面的基础，加上完整的微服务治理能力，能充分帮我们解决在微服务拆分后的管理和运维问题，所以这部分内容是相当重要的。
技术组件
我们这里探讨的是中台能力不是只堆砌技术组件，不是缺消息队列和定时任务调度框架就装一个 RabbitMQ 和 Quartz，然后就抛给业务开发去使用，我们而是思考如何让业务开发更好更快速地上手使用，如何让多个项目组使用时保证组件的稳定和可用性。比如项目需要使用某个技术组件，我们可以经历以下几个步骤：
写一个文档，告诉开发需要哪些依赖，引用什么样的配置即可。
发现每个人都要这样很麻烦，我们即把依赖引入父工程或公共依赖。
发现每个人还需要配各种配置后，我们可剩下不能减少的配置，如服务名，其他的都放在远程配置中心或环境变量或其他地方。
增加 UI 可视化能力，可视化管理能力。
标准化，微服务化，业务域、系统级、公司级别统一微服务，多租户能力，如给每个应用分配权限，单独的进行数据操作，维护，管理。
发现需求，优化迭代。
通常一般的只是做 1,2,3 点，稍微好点的可以会增加第四点，如果真正的落地技术中台，应该在第四点，第五点和第六点发力，进行能力的抽象，进而形成标准化的能力，还能非常快速的提供给业务和其他技术部门使用，维护成本也低，这才是真正能为团队和业务带来价值的地方，也是提高研发效能和组织效率的途径，这三点就需要单独去开发和建设了。
这部分的能力就是让我们开发、测试、运维人员能快速的使用这些技术组件帮助我们解决特定问题，并且利用这些能力开发出公共微服务，提供给公司使用。
公共基础服务和技术服务
对于公共基础服务和技术服务其实包含的东西也很多，只要能抽取出公共能力的服务或技术，都可以单独拿出来进行操作：
公共基础服务：用户权限服务，业务配置服务, 通知服务，数据分析服务等。
技术服务：缓存服务，分布式 ID 服务，消息队列，分布式任务调度服务等。
比如权限服务，那么是否考虑整个公司或者大的业务域是一套权限中心，这个权限中心应当是多租户的，传统的老架构很多是各自独立的，那这里我们就考虑是否可合并。我这里没有列完，这部分内容其实是非常多的，也是非常重要的，是真正提高开发效率和效能的地方，往往也是很多公司欠缺的部分，有些公司可能有部分能力，更多的时候还是像我们之前说的，只是纯技术组件，而不是服务，耦合度也较高，也没有真正的支持多用户能力，使用起来也很繁琐，这样的东西和传统的架构方式并没有太大区别，也没有真正的为业务和开发去考虑，很有可能还是各自为政重复造*，最终造成流程的繁琐和数据的不一致。
技术组件、公共基础服务、技术服务这三块是真正需要公司下大力气去规划实现的内容，也是比较容易把控和落地的，这里面操作的空间非常之大，做好之后给业务带来的好处是直接可见的。
DevOps&&AIOps
DevOps 层面，我们这里讨论的可能不是技术层面的实现，如如何使用 jenkins，写好 pipeline 进行 CICD，也不是如何利用 docker + k8s+Jenkins 做到动态 CICD 等，也不是如何做好 DevOps 模板，而更多的是 DevOps 现状做一些思考。
首先在实施 DevOps 时候，我们发现很多项目组只是在 DevOps 工具链方面做了很好的处理，比如采用 CI/CD 方法论，加上 git, Gradle, maven ,jenkins，jacoco, sonar, CodeDeploy, Ansible,docker 等等工具链，已经让 CICD 在企业和公司里实行了起来，并且还能运用好运维平台，在自动化方面做了很多工作，这些都给企业带来了好处和效率的提升。
其次，DevOps 是可以贯穿需求，设计，开发，测试，上线，运维等多个方面的，它应该是要以应用为中心，以组织作为依托，来促进公司整个效能的提升，进而还能推动创新能力的增强，和促进人才、组织的优化，这才是有价值的 DevOps。
不足的方面是文化、组织、流程方面，我们发现技术方面很多问题其实是管理的不足带来的，DevOps 为了打破开发和运维墙而产生的文化在传统企业的组织层面还比较难调整，泰勒的金字塔管理结构还是持续发挥作用，部门墙还是继续维持，作为技术实施方的我们，肯定是希望完美的解决问题，在一开始就让团队或者组织进行调整，其实这对于很多企业来说是不太现实的，但我们发现随着 CI、CD、CO 能力落地，组织间的配合越来越多，人员的技能在逐步渗透，这时在无法立马解决组织层面问题的时候，可以逐步的让团队发生技术融合，职责传递和培训，从而推动团队的整合，形成我们期望的，融合的 2 个披萨团队，完成真正的 DevOps 文化和工具的全面落地。
AIOps 层面：
在我们 Ops 运维方面，我们已经从过去的人工运维走到了如今的自动化运维，但我们发现这里的自动化只能是管控台，工具和脚本层面，如果在人的思想方面做到自动化其实是比较困难的，那也必将造成我们人工的进行分析和决策，也需要人工的进行检测点及规则点的录入，所以这也是 AIOps 能帮我们带来的好处，AIOps 主要还是在 AI 层面发挥它独有的优势，在数字化运营，智慧运维这块发力，这部分内容也是建设中台可以考虑的部分。
效能：
我们的目标是持续的交付有价值且稳定的软件，效能方面其实是贯穿整个项目的，我认为它不单单指研发效能这一个点的，我们应该是思考如何站在整体的角度上去衡量团队和项目效率的提升，犹如坐在飞机上俯瞰大地，这里一个好的做法是成立一个平台型效能微团队，能定期的对项目和团队进行梳理，可以是任意方面，并可以借助一些产品和方法进行辅助，如利用看板，限制在制品数量等。另外这个团队重要的工作是能抽时间和站在更高的角度去发现整个中台的价值，改进点和缺陷，如形成好的公共支撑服务和标准化的服务，对中台进行不断优化和迭代。
时间仓促，涉及的东西很多，我们这次只谈论了技术中台的部分内容，当然整个的范围远远不止这几部分，抛砖引玉，希望有机会跟大家一起交流心得。
作者介绍
朱德明，腾讯云技术架构师，十年软件开发经验，《重新定义 Spring Cloud 实战》作者之一，业界首个微服务标准核心编写者之一，长期从事微服务和云原生方面的工作，研发过多款微服务产品，主导和参与了多个大型企业微服务架构和云原生架构的设计，咨询等工作。在微服务，云原生，互联网解决方案等方面有着丰富的实战和落地经验。
DDD（领域驱动设计）分层架构
DDD 分层架构各层定义与职能：
展现层：它负责向用户显示信息和解释用户命令，完成前端界面逻辑。这里的用户不一定是使用用户界面的人，也可以是另一个计算机系统。
应用层：它是很薄的一层，负责展现层与领域层之间的协调，也是与其它系统应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，不保留业务对象的状态，只保留有应用任务的进度状态，更注重流程性的东西。它只为领域层中的领域对象协调任务，分配工作，使它们互相协作。
领域层：它是业务软件的核心所在，包含了业务所涉及的领域对象（实体、值对象）、领域服务以及它们之间的关系，负责表达业务概念、业务状态信息以及业务规则，具体表现形式就是领域模型。领域驱动设计提倡富领域模型，即尽量将业务逻辑归属到领域对象上，实在无法归属的部分则以领域服务的形式进行定义。
基础设施层：它向其他层提供通用的技术能力，为应用层传递消息（API 网关等），为领域层提供持久化机制（如数据库资源）等。
台、领域驱动设计及微服务
分析和设计模式的演进
在单机和集中式架构时代，系统分析和设计往往都是分阶段割裂进行的，容易导致需求、设计与代码实现的不一致，软件上线后才发现很多功能不是自己想要的，而且在这种模式下，软件也不能快速响应需求和业务变化。
领域驱动设计（DDD）打破了这种隔阂，它提出了领域模型概念，统一了分析、设计和开发语言和过程，使得软件能够更灵活快速响应需求变化。
软件分析和设计方法经历了三个阶段的演进：
第一阶段是单机架构时代：采用面向过程的设计方法，系统包括 UI 层和数据库两层，采用 C/S 架构模式，整个系统围绕数据库驱动设计和开发，新项目总是从设计数据库及其字段开始。
第二阶段是集中式架构时代：采用面向对象的设计方法，系统包括 UI 层、业务逻辑层和数据库层，采用经典的三层架构，也有部分应用采用传统的 SOA 架构，这种架构易使服务变得臃肿，难于维护拓展，伸缩性能差。这个阶段系统分析、软件设计和开发大多是分阶段进行的。
第三阶段是分布式架构时代：由于微服务架构的流行，采用领域驱动设计方法，应用系统包括 UI 层、应用层、领域层和基础层。这个阶段融合了分析和设计阶段，通过建立领域模型，划分领域边界，做到领域模型既设计，代码与设计保持一致。
领域驱动设计主要优势：1.业务导向。2.业务逻辑内聚，应用边界清晰。3.建立领域模型优先。4.分析、设计、代码和数据有机结合。5.代码即设计。6.扩展性好。
数据驱动设计主要特点：1.技术导向。2.数据库优先。3.代码不能反映业务和设计。4.业务逻辑分散。5.扩展性不好。
领域驱动设计概述
2004 年 Eric Evans 发表《Domain-Driven Design –Tackling Complexity in the Heart of Software》 （领域驱动设计 ）简称 Evans DDD。但在软件开发领域一直都是雷声大，雨点小，领域驱动设计核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。这几年之所以开始火起来，主要功劳要归功于队友“微服务”，领域驱动设计与微服务架构天生匹配。
领域驱动设计（DDD）是一种处理高度复杂域的设计思想，试图分离技术实现的复杂性，围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演化等问题。团队利用它可以成功的开发复杂业务软件系统，在系统变大时仍能保持敏捷性。
领域驱动设计分为两个阶段：
1.以一种领域专家、设计人员、开发人员都能理解的通用语言作为相互交流的工具，在交流的过程中发现领域概念，然后将这些概念设计成一个领域模型；
2.由领域模型驱动软件设计，用代码来实现该领域模型。
领域驱动设计的核心诉求是让业务架构和系统架构形成绑定关系，当我们去响应业务变化调整业务架构时，系统架构的改变也会随之发生。在领域驱动设计中业务架构的梳理和系统架构的梳理是同步进行的，其结果是设计出的业务上下文和系统模块结构是绑定的。同时技术架构也是解耦的，可以根据划分出来的业务上下文的系统架构选择最合适的实现技术。
领域驱动设计包括战略设计和战术设计两个部分。战略设计主要关注按领域定义，在限界上下文内形成统一语言，提升业务和技术的沟通效率； 战术设计主要关注领域设计在落地时与设计模型及实现模型的差异性，减小业务和技术之间的鸿沟。（本文对 DDD 知识点不做详述，如需了解或学习，请查阅《领域驱动设计：软件核心复杂性应对之道》和《实现领域驱动》）。
领域驱动设计可能会给你带来以下收获：
1、领域驱动设计是一套完整而系统的设计方法，它能带给你从战略设计到战术设计的规范过程，使得你的设计思路能够更加清晰，设计过程更加规范。
2、领域驱动设计尤其善于处理与领域相关的高复杂度业务的产品研发，通过它可以为你的产品建立一个核心而稳定的领域模型内核，有利于领域知识的传递与传承。
3、领域驱动设计强调团队与领域专家的合作，能够帮助团队建立一个沟通良好的团队组织，构建一致的架构体系。 领域驱动设计强调对架构与模型的精心打磨，尤其善于处理系统架构的演进设计。
4、领域驱动设计的思想、原则与模式有助于提高团队成员的架构设计能力。
5、领域驱动设计与微服务架构天生匹配，无论是在新项目中设计微服务架构，还是将系统从单体架构演进到微服务设计，都可以遵循领域驱动设计的架构原则。
为什么领域驱动设计是微服务架构的最佳设计方法？
领域驱动设计作为一种架构设计方法，微服务作为一种架构风格，两者从本质上都是为追求高响应力目标而从业务视角去分离复杂度的手段。 两者都强调从业务出发，其核心要义强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力（演进式架构） 。
领域驱动设计主要关注：业务领域，划分领域边界；构建通用语言，高效沟通；对业务进行抽象，建立领域模型；维持业务和代码的逻辑一致性。
微服务主要关注：运行时进程间通信，能够容错和故障隔离；去中心化管理数据和去中心化治理；服务可以独立的开发、测试、构建和部署，按业务组织全功能团队；高内聚低耦合，职责单一。
如果你的业务焦点在领域和领域逻辑，那么你就可以选择 DDD 进行微服务架构设计。
中台、DDD 与微服务
中台的定义来源于阿里的中台战略（详见《企业 IT 架构转型之道：阿里巴巴中台战略思想与架构实战》钟华编著）。2015 年年底，阿里巴巴集团对外宣布全面启动阿里巴巴集团 2018 年中台战略，构建符合数字时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。
中台的本质是提炼各个业务条线的共同需求，并将这些功能打造成组件化产品，然后以 API 接口的形式提供给前台各业务部门使用。前台要做什么业务，需要什么资源可以直接找中台，不需要每次去改动自己的底层，而是在底层不变动的情况下，在更丰富灵活的“大中台”基础上获取支持，让“小前台”更加灵活敏捷。
中台战略的主要目标是实现公共需求和功能的中台化共享，减少重复建设和投入，为前台提供统一的一致服务。至于前台应用是否可以有数据库？抑或采用什么样的开发技术，这些都不是重点，重点需要考虑的是那些公共需求和需要共享的功能是否通过中台的方式被前台使用了。
领域驱动设计中领域的定义：一个领域本质上可以理解为就是一个问题域，只要是同一个领域，那问题域就相同。所以只要我们确定了系统所属的领域，那这个系统的核心业务，即要解决的关键问题、问题的范围边界就基本确定了。领域的本质是问题域，问题域可能根据需要逐层细分，因此领域可分解为子域，子域或可继续分为子子域。。。
在领域驱动设计中根据重要性与功能属性将领域分为三类子域，分别是：核心子域、支撑子域和通用子域。决定产品和企业独特竞争力的子域是核心子域，它是业务成功的主要因素和企业的核心竞争力。没有个性化的诉求，属于通用功能的子域是通用子域，如登陆认证。 还有一种所提供的功能是必须的，但不是通用也不是企业核心竞争力的子域是支撑子域，如单证。
DD:核心域、支撑域和通用域
中台、领域以及微服务属于不同层面的内容，稍作分解我们理清他们之间的关系。
以保险领域为例，业务中台大致可分为两类：第一类是提供保险核心业务服务的专属业务中台（如承保、理赔等业务）；第二类是支撑核心业务流程完成保险全流程的通用中台（如主数据、客户、用户以及电子保单等）。
专属业务中台是保险企业的核心竞争力，对应 DDD 的核心子域。通用中台对应 DDD 支撑子域和通用子域。不同领域可根据领域大小进一步细分多个子域，多个子域可对应到一个业务中台，一个业务中台也可能会分解成多个子域。
中台、领域以及微服务
微服务是技术实现和部署的范畴，实现领域或中台的业务逻辑，为前台应用提供服务。领域根据限界上下文可以设计为多个微服务，而如果限界上下文过大，一个微服务也可能会包含多个子领域。
中台是由多个业务条线的共同需求所构成，是需要共享的业务功能和服务单元的集合，一个中台可由一个微服务来实现，也可根据领域驱动设计和微服务拆分原则细分为多个微服务，多个微服务功能集合共同组成一个中台。
基于 DDD 的微服务设计方法
DDD 设计包括战略设计和战术设计两个部分。在战略设计阶段主要完成领域建模和服务地图。在战术设计阶段，通过聚合、实体、值对象以及不同层级的服务，完成微服务的建设和实施。通过 DDD 可以保证业务模型、系统模型、架构模型以及代码模型的一致。
本部分主要讨论领域设计方法，如对战术设计和开发方法感兴趣可查阅 DDD 战术设计相关资料。
DDD 领域设计过程包括产品愿景、场景分析、领域建模和服务地图阶段，也可根据需要裁剪不必要的阶段和参与角色。领域驱动设计一般经历 2-6 周的时间，领域模型设计完成后，即可投入微服务实施。
1、产品愿景
产品愿景是对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等策略层信息达成一致，避免产品在演进过程中偏离方向。
阶段输入：产品初衷、用户研究、竞品知识和差异性想法 。
参与角⾊：业务需求方、产品经理、开发组长和产品发起人。
阶段产出：电梯演讲画布。
2、场景分析
场景分析是针对核心用户及顶层服务的一种定性分析，从⽤户视角出发，探索问题域中的典型场景分析。同时也是从用户视角对问题域的探索，产出问题域中需要支撑的场景分类及典型场景，用以支撑领域建模阶段。
阶段输⼊：核⼼干系人和服务价值定位。
参与角色：产品经理、开发组长和测试组长。
阶段产出：场景分类清单。
3、领域建模
领域建模是通过对业务和问题域进⾏分析，建⽴领域模型，向上通过限界上下⽂指导微服务的边界设计，向下通过聚合指导实体的对象设计。领域建模主要采用事件风暴方法。
阶段输入：业务领域知识和场景分类清单。
参与角色：领域专家、架构师、产品经理、开发组长和测试组长。
阶段产出：聚合模型和限界上下⽂地图。
4、服务地图
服务地图是整个产品服务架构的体现。结合业务与技术因素，对服务的粒度、边界划分、集 成关系进⾏梳理，得到反映系统微服务层面设计的服务地图。
阶段输⼊：限界上下⽂地图。
参与角⾊：产品经理、开发组长、测试组长和产品发起人。
阶段产出：服务地图。
在进行服务地图设计时需要考虑以下要素：1. 围绕限界上下⽂边界。2. 考虑不同业务变化速度/相关度、发布频率。3. 考虑系统非功能性需求，如系统弹性伸缩要求、安全性要求和可⽤性要求。4. 考虑团队组织和沟通效率。5. 软件包限制。6.技术和架构的异构。
正如老马说的采用微服务的企业需具备一定的高度，如文化、组织和技术，DDD 同样也需要站一定的高度。如果高度不够，我们是否可以站在巨人的肩上呢？
在领域模型和微服务设计时，守住领域模型和边界，各司其职，才能长治久安！
谨记：边界！边界！边界！