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

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

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

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

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

　　

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

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

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