引言

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

spring cold业务领域驱动微服务设计

业务领域

业务子域

通过与公司核心团队一番交谈，我们了解到了主要需求是：客户在网上叫车，系统自动分配离客户最近的车。公司的核心竞争力是让客户以最快的速度叫到车。

和公司业务人员调研后，我们把公司业务分成三个子域：(用户/司机）身份认证子领域、打车管理子域及报表子域。

打车管理子域是核心子域，我们以打车管理子域为例提取网上叫车的业务术语。

业务术语表

业务规则：

打车：经认证的用户，打开叫车应用，首先会定位，会在地图上显示附近的汽车。用户发起叫车后，系统会自动通知离客户最近的司机。用户到达目的地后，系统自动从用户关联的账户扣款。

分配司机：系统为用户分配一个最近的司机

计费：系统根据用户所乘车的当前位置进行计费

扣款申请：用户到达目的地后，系统根据路程的长远向用户的银行账户发送扣款申请

打车管理子域依赖于身份认证子领域。只用经过认证的用户和司机才可以使用打车管理App，只有有足够信用额度的用户才可以打车。运营报表依赖于打车管理子领域，运营报表目前仅需要从打车管理里提取用户的消费记录，后面估计还会有其它需求。

角色和对象：

以打车管理限界上下文，分析参与者

在打车管理限界上下文里，有两个明显的角色：用户和司机

用户：在打车App有有效的账号，有足够的信用，叫车时要有精确的位置

司机：需要在打车App上注册的，有有效的身份证明和驾驶证，无不良记录。收到用户的订单后，将用户从起始点安全地送到目的地。

细致分析后，我们发现还有一个隐式的对象：订单。从业务来看，最终的目的还是为了多拿订单，从这个角度来看，订单是比比用户和司机都重要的业务对象。

业务状态：

以打车管理限界上下文，分析业务状态

用户已叫车、用户已上车、用户已到达

.微服务设计

打车管理微服务的设计

微服务里的微并不是越小越好。微服务和分布式架构是相关联的。分布式架构第一原则是能不做分布式就不要分布式，对于微服务，是在能满足业务需求的情况下，尽可能的不微。所以，对于新的需求，微服务的粒度可以和限界上下文一对一映射。当需求逐渐明晰了后，如果业务需要，微服务的最小粒度可以放到聚合的级别。

因为是创业公司，对很对需求了解都还不够细，我们微服务粒度和限界上下文对应，现有的版本是V1.0

.

聚合的设计

领域服务的设计

领域事件

资源库

定义订单资源库类OrderRepository。OrderReporsitory接口目前定义一种方法：findByUserID，返回和该ID相关联的用户的所有订单

OrderRepository基于Repository接口。在Repository接口里定义三种方法：add、remove、update。用来增加、删除、更新订单

总结

以 上就是我对  Java开发大型互联网-如何利用spring cold业务领域驱动微服务设计  问题及其优化总结，分享给大家，觉得收获的话可以点个关注收藏转发一波喔，谢谢大佬们支持！

最后，每一位读到这里的网友，感谢你们能耐心地看完。希望在成为一名更优秀的Java程序员的道路上，我们可以一起学习、一起进步！都能赢取白富美，走向架构师的人生巅峰!

想了解学习Java方面的技术内容以及Java技术视频的内容可加群：722040762 验证码：简书（666 必过）欢迎大家的加入哟！