DDD四色建模实战之体育活动建模

一、说明

在DDD实战环节中已经做了社交类-博客帖子平台服务的建模实战，并有了一些代码样例。这里我们继续实战之旅。通过NBA篮球体育赛事场景来走一遍DDD四色建模的过程，并进行代码实战。

二、篮球比赛活动建模

2.0 业务时序分析

这里我选择了四大场景来做业务时序分析，分别是选秀活动，赛程，比赛活动统计，球员交易。

篮球运动领域–业务时序.png

2.1 选秀活动

1.业务描述

参加选秀的球员在符合选秀规则的情况下可以参加一年一度的NBA选秀大会，并通过抽签球队选人的方式确定新秀球员，其中前三位被选中的球员分别是状元，榜眼，探花。

2.规则描述

•男性，年龄满19周岁，海外球员年龄满22周岁•新秀球员两次确认参加选秀•选秀分为两轮

由于篇幅问题，这四大场景都不会一一阐述建模过程，首先看选秀活动的四色建模图，选秀活动中分析出的业务关键时刻按业务时序有选秀报名记录，选秀活动记录，新秀签约记录。另外一方面通过选秀活动我们可以大致确定球员，球队之间的关系，为后续业务场景做基础。

选秀活动-四色模型.png

2.2 赛程活动

1.业务描述

赛程活动是NBA官方进行定制，如遇到特殊情况可以延期，赛程活动需要确定主队，客队，裁判，开始时间等信息。球队球员跟进赛程进行比赛。赛程按一年一度分，同时有不同的赛程属性，比如季前赛，常规赛，季后赛等。按活动类型属性分为正常比赛，加时比赛，全明星赛，附加赛。

2.规则描述

•每个球队每年参与82/72场比赛•季后赛7局4胜制其他规则参考： https://www.zhihu.com/search?type=content&q=NBA%E8%B5%9B%E7%A8%8B%E8%A7%84%E5%88%99^[1]

这里的赛程活动算是一个核心业务领域之一了，在赛程活动的四色模型中主要分析出了两个业务关键时刻，分别是比赛活动和赛程表。比赛活动算是核心业务了，因此涉及到的球队，裁判，日期等都是重点关注对象。

赛程表定制-四色模型.png

2.3 比赛活动统计

1. 业务描述

比赛球队双方在主队所在球馆比赛，比赛前确定首发阵容，确定裁判人员。由于目前疫情期间并没有球迷入场，因此这里不对座位，球票做业务分析。

2. 规则描述

•比赛分为4节，每节12分钟，如果最后主队客队比分相同则进行加时赛，加时赛每场5分钟。•每场比赛暂停次数是7次，加时赛3次•每个球员比赛犯规不得超过5次，超过则被罚本场比赛后续不能上场•每次罚球时间10秒•每场比赛裁判人员3人

由于比赛活动会受到赛程的制约，因此在赛程表下的比赛活动一般类似于排班预设。当真正进行一场比赛的时候我们的关注点自然会聚焦在球场，包括主队，客队，比赛开始时间，各个队的球星表现等。因此比赛活动里我们会把焦点放在比赛活动中出现的各种事件上，这个场景非常适合使用事件驱动的方式去解决球队数据统计，球员数据统计的问题。

比赛活动-四色模型.png

2.4 球员交易

1.业务描述

球队或者球员都有权要求交易，交易需要通过球队与球员或者经纪人进行沟通，签订协议和合同，并接受官方监管。

2.规则描述

•工资帽规则•薪金对等规则•交易特例•拉里伯德条款•莫宁规则•新秀交易保护条例•先签后换•选秀权和现金•霸王条款•10天短合同•伤病特例条款•中产特例

很多打篮球或者喜欢关注NBA的读者都知道关于NBA球员交易是每年都肯定会发生的，比如詹姆斯去热火，回骑士，到湖人。明星球员在球队中的流动总是惹人关注的。NBA篮球交易的过程和涉及到的规则，以及他们拿到的薪资都是可以模拟的。

这里我们只通过交易记录这个业务关键时刻来代表发生了球员球队交易。当然一次交易肯定会涉及到不同的角色，团队。相应的球员球队的权责关系，权益关系也会发生变化。因此交易对象，协议/合同，交易规则，球队等这些都变成了普通的人事物来辅助交易业务的发生。

球员交易–四色模型.png

2.5 球员签约与交易UML类图

篮球选秀签约交易领域UML类图.png

2.6 活动赛程与数据统计UML类图

篮球赛程比赛数据统计领域建模UML类图.png

2.7 值对象与实体

通过上面的UML类图可知，配置类数据基本都可以作为值对象存在，但是有些名词实体其实在特定场景下可以算作实体。比如球队。球队的话在交易，比赛的时候其实是有行为的，但是球队里的很多属性其实是不怎么变化的，而且联盟里就30只球队。球队基本属性很少变化的情况下球队的这些属性可以作为值对象被球队引用。

三、领域与上下文分析

3.1 成员域

在NBA中涉及到很多人员角色，分工不同自然职能不同，比如球员，球队，裁判，经纪人，教练，队医等。因此这些人的基本信息可以单独管理起来，为后续其他领域做基础。也可以单独独立出来做子领域服务。

3.2 活动域

由于NBA篮球比赛是娱乐体育性质，每年的总冠军争夺之旅都异常艰难，也吸引人。深入了解NBA的同学可以知道，NBA在美国其实影响力并不特别大，因此总会明里暗里整出很多活动，吸人眼球。核心的当然是比赛活动了，另外就是选秀大会，圣诞大战，全明星赛，海外比赛等。因此关于比赛活动，赛程安排等也可以单独作为一个子领域存在。

3.3 规则域

规则域在上面的分析中并没有特别突出这个规则实体，从业务角度来看，选秀有选秀的规则，交易有交易的规则，比赛有比赛的规则，因此规则是支撑业务的存在。举个例子，当球员参加选秀的时候需要按规则提交信息校验信息。这些规则奠定了业务基础，对规则的描述和维护可以不依赖业务，可以单独作为一个子域。

3.4 统计域

从球迷，解说的角度看球队统计，球员统计是非常必须的，因为这些统计数据经常被人拿来解读，比如湖人17冠，三连冠等。球队球员的发挥也不是嘴上说说，球场表现能一锤定音的。有数据来说话，通过不同的维度看球员表现才更能体现球员价值。另外一方面统计数据的来源依赖于比赛活动中产生的数据，其他训练数据，大学NCAA的表现数据在NBA的比赛统计中看价值不大。这里的统计域给出的数据可以被更多人解读，带来更多业务可能。

3.5 交易域

在NBA中比较引人注意的其他事项就是球员球星的转会了，从一个城市到另外一个城市，所带来的影响其实可大可小。关于NBA的交易风波几乎每年都有。毕竟球星也希望总冠军和票子双赢。那么在NBA中交易活动可不是跟买菜一样随便，毕竟有很多规则限制。另外球员的价值和对未来的期望都不一样，球队对球员的期望也不一样，一旦发生交易对各方都有影响，因此交易这里也需要单独作为一个子域来描述球员球队之间的变动关系。更多的就是关于交易中涉及到的合同，资产等信息的变化。

3.6 资产域

资产域这里主要描述NBA官方和球队中的一些资产情况，比如选秀权，待交易或者兑现的特例等，另外就是球队收入与联盟收入，在后期进行完善的时候资产自然是要慢慢剥离开来看。

四、其他

由于没有接触过篮球相关的技术人员或者资深球迷，没有与之进行交流，可能在建模过程中对现实场景会有些出入。当然本文也是在大量寻找网上资源进行建模分析的。如果哪里不对或者想深入探讨一下建模细节可以关注公众号与我联系。感兴趣的可以继续基于此构建NBA篮球活动运营管理系统。

References

[1] https://www.zhihu.com/search?type=content&q=NBA%E8%B5%9B%E7%A8%8B%E8%A7%84%E5%88%99: https://www.zhihu.com/search?type=content&q=NBA%E8%B5%9B%E7%A8%8B%E8%A7%84%E5%88%99