企业应用架构研究系列一:业务拆分

  现代软件开发和以前的软件开发有很大的不同,以前软件一般都会根据业务流程,设计程序的入口和程序的出口,即软件耦合性很强。随着软件技术的不断发展和DDD领域设计模型的不断深入研究,在微服务化开发框架的大力推广下,Docker技术和K8s 技术的普及,新一代的企业应用架构再次革新了软件行业。

  无论是软件开发者还是应用架构者,我认为只是一个工作角色而已,没有必要分的太清晰,作为软件行业从业者,大家都应该具备软件的设计架构理念。最近深读了《Microsoft.NET企业级应用架构设计》和《企业应用架构模式》这两本书,还是启迪很深,特别是开头这句话“完美的设计不是保罗万象无所不有,而是完整自洽不可精简”。

  开启企业应用架构之旅,首先我们需要有一个专门的架构描述语言工具,就是UML 统一建模语言,这个是也是软件设计领域被国际公认的标准。后期我会单独抽出一个章节进行UML建模语言的Knowledge Discovery(探索)。本章之谈谈企业应用架构中对业务拆分的理解。

  首先进行分功能分解,分解的原则就是,符合通用开放-关闭原则 , 将每个业务逻辑模型进行封装,关闭对该业务的所有业务数据的操作,开放关联接口或服务。通俗点讲,就是我的地盘我管,不允许非授权操作我的数据和业务,所有操作统一接口。

  

  每个业务领域里面,以应用的控制为中心,对业务的活动记录和业务实体的属性进行不断的操作,而这些操作都是基于业务模块里面定义好的规则进行,这种逻辑有着严格的控制,而且这些控制又不依赖外部影响。就是自己的逻辑故事自己来撰写,同时业务模型对外提供标准的操作说明,而这些操作由 单独的关联映射去管理。这样就可以将自己领域内的事情自己来维护。关联映射部分,就是负责协调对外的承诺,自己内部无论怎么调整,我对外的承认或关联不会变。

  业务领域拆分,就是把一个生态环境拆分若干模块,业务生态是千变万化的,是不断发展和演变,每天的故事都是不一样的。而拆分的业务领域模型,就是一个工厂,工厂内的机器控制产品的装配,产品的包装,产品的质检,工厂生产环节不关心外部的事情,外部的事情都由工厂的对外经营负责,自己站好自己的岗。

  总结一下,封装了领域内的故事,开放对外的承诺,专业的事情由专业的模块处理。业务拆分达到这个目标,就能在整个企业应用架构中保持稳定的架构模型。

 

你可能感兴趣的:(企业应用架构研究系列一:业务拆分)