气象业务驱动模型（MODD）设计

昨天提到了这个MODD（Meteorological operations Driven Model），我自创的一个技术名词，跟大家解释一下：其实这不是一个新概念，新瓶装旧酒，但我觉得用在气象业务系统建设中还比较合适，就拿来说说吧。

【气象业务驱动模型（MODD）的来龙去脉】

当前我们的气象部门也在努力融入数字化转型的浪潮中，气象现代化的主要评估指标就是业务现代化，业务现代化就需要先进的信息化手段。信息化工作已经成为气象部门增强气象服务能力的工作重点，甚至由各部门一把手组成了“信息化领导小组”，专门推进信息化工作。信息化这个词近几年使用频率非常高，气象部门的信息化广义上来理解是指信息资源开发与信息技术广泛深入应用的一个较长历史阶段，包括数字化、网络化、智能化、民主化等，信息化程度的表现形式主要体现在气象业务上，因此一层层深入后的落脚点还是在气象业务上。我说过这是一个我自创的技术名词，其实也是刚刚创立出来，从《你的气象业务完成数字化转型了吗？》一文中开始，我就在讨论气象业务信息化的话题，先后推出《气象业务平台建设何时了？》、《关注业务比钟情技术更重要》等文章，一直到昨天《做气象业务系统，先别急着开发》正式提出这个概念。气象业务驱动模型（MODD）的提出是为了解决气象业务信息化过程中气象业务和信息化技术的有效融合，不只是气象业务系统开发过程中的需求有效转化以及信息化架构的合理设计，还包含气象业务的合理改进和新技术有机融合的相关思考。不可否认，虽然我做了一些思考，也提出MODD是为了解决气象业务在发展过程中的一些问题，但还没有形成一套完整的知识体系和可持续支撑的方法论，在此也希望业内同行们一起来讨论，不断碰撞出新的火花，共同完善气象业务驱动模型（MODD）的理论基础。

【气象业务驱动模型（MODD）的组成部分】

气象业务驱动模型（MODD）从字面上直译可分为两个部分，气象业务与驱动模型，重点是气象业务，这是核心，驱动模型是方法，是信息化的技术手段。昨天提出这个概念时我简单说过，灵感来源于BMD（Business Model Driven）和DDD（Domain-Driven Design）的组合。业务模型驱动（BMD）是一种业务导向和驱动的软件体系，也是基于业务模型的概念结构表达体系，用来描述、分析、设计、构建、集成、扩展、运行的管理信息系统，是企业业务运行的基础平台架构。领域驱动设计（DDD）是目前比较流行的软件建模设计方法，早在2004年埃里克.埃文斯（Eric Evans）就发表了《领域驱动设计》（Domain-Driven Design-Tackling Complexity in the Heart of Software）这本书，从此DDD诞生。DDD核心思想是通过领域驱动设计方法定义领域模型，从而确定业务和应用边界，保证业务模型与代码模型的一致性。BMD指导我专注于气象业务并将业务驱动思想融入到解决气象业务发展的问题中，DDD教给我建设气象平台的过程中气象业务模型的创建，确定业务和应用边界，使用通用语言进行气象业务和软件开发的需求转换。所以气象业务驱动模型（MODD：Meteorological operations Driven Model）是一个合成概念，就是在气象业务这个特定的领域内，去深入研究气象业务特点，做到正确理解气象业务，清晰表述气象业务，并通过建模方法，以解决气象业务系统规模过大、功能复杂的软件复杂性问题，从而开发出我们想要的气象业务系统平台，提升气象业务信息化水平，加快推进数字化转型的进程。

DDD设计图例

【气象业务驱动模型（MODD）的应用实践】

在第一节中我谈到MODD是个新鲜的概念，虽然技术理论是新瓶装旧酒，但是他有很强的实践特点，因为我们气象业务系统平台的开发基本上每年都在进行，并且投入在逐步增加。提出这个概念跟我们目前所处的数字化转型过程是分不开的，尤其是发展智慧气象为目标的历史阶段。数字化经济时代业务的数字化转型是必然的，一系列气象服务能力建设的重大工程投入其实也是在努力完成数字化转型。说到这里就不得不提到中台、微服务、业务上云等“十三五规划”中气象信息系统的建设过程。相信很多气象业内同行都在这个建设中遇到不少困惑。中台战略在气象部门落地还有很长的路要走，因为涉及到组织架构的调整并且需要承担昂贵的试错成本（推荐大家阅读《企业IT架构转型之道》一书），在这里不做具体讨论！（内心还是有个小期望去专题讨论，哈哈！）“微服务”架构是目前比较流行并且相对成熟的软件技术架构，这里就有MODD的用武之地了。我们气象部门对新的技术从来都是充满热情，这一点也是我们气象从业者非常欣慰的地方，尤其是IT技术。“微服务”这种软件架构也是比较适合应用在气象业务系统的开发中，因为随着业务的不断发展，业务系统越来越庞大、越来越复杂、越来越独立（烟囱林立、数据孤岛、重复建设问题突出），到了该进行大调整的时候了，（这里的讨论对没有从事信息化工作的同行来说有点绕，可以略过不看。）于是在业务系统建设中都纷纷转向微服务架构的开发。在遵循微服务架构的实施过程中，发现存在太多的不确定性，为什么会这样呢？因为大家都不明白业务系统的微服务到底应该怎样划分，业务边界不清晰，功能模块和微服务模块混为一谈，最后好不容易划分出来发现这个微服务架构成为了一个“四不像”，不得不推翻继续按照单体架构形式开发（再划分工期就过了！）。在昨天提出MODD这个概念时我说过，解决这个问题的关键在于人，这个人就是要懂得气象业务驱动模型设计的人，这个人所承担的职能一方面要深入理解气象业务，懂得气象业务的核心和关键点在哪里，另一方面还要懂得将业务体系通过模型创建表述出来，可以说是个懂业务和IT技术的复合型人才，其实现在互联网公司也非常缺少这样的人才，那就是架构师，一个合格的架构师的培养周期要10-15年，可想而知这有多金贵！

关于应用实践的过程在这里不细说了，踩过很多坑、遇到很多麻烦，并且在我的工作中还需要不断总结积累，认真思考，真正使用MODD的思想解决掉气象业务发展中的实际问题才是正道！祝大家五一劳动节快乐，也欢迎您加入到讨论中，留下您的宝贵意见！