关于业务架构的一些思考与实践

1.业务架构是什么

随着业务的发展，我们面临的业务场景也越来越复杂，而为了解决这些复杂的业务问题，我们的实现方案也越来越复杂，而复杂度就会带来理解、维护、迭代的难度增加。摆在我们面前的问题，就是如何在实现复杂业务时，控制好系统的复杂度。

业务架构的核心目的，是控制系统的复杂度。通过业务架构，来传递规范与约束。引导开发人员在实现业务功能时，进行合理的业务问题分解，结构化、抽象化设计，保证系统的可维护性与可读性，延缓系统腐化速度。

2.分层架构

传统的三层架构分为表现层、业务逻辑层、数据访问层，各层之间通过接口交互，通过Model来传递数据。这种三层架构非常简单，基本没有开发门槛，往往适用于功能简单的单体应用。当业务较复杂，对稳定性和扩展性有一定要求时，我们往往会采用微服务分层架构。与传统的三层架构相比，微服务架构里将业务逻辑层拆分为两部分，一部分是针对业务场景的业务网关层，一部分是针对业务逻辑的业务服务层。我们往往将逻辑功能放在业务服务层，实现业务的隔离与复用。

微服务分层架构能满足大多数业务，这也是我们最常见的业务架构之一，但是它也依然存在问题。业务网关层和业务服务层之间的边界，需要开发人员理解并遵守分层规范才行，但是实际开发过程中大家的理解不一致，经常会出现所有逻辑实现都在业务网关层、业务服务层只提供数据，以及出现所有逻辑实现都在业务服务层、业务网关层只提供调用入口现象。前者导致服务层“太瘦”，上层复用时相关业务逻辑需要重新实现一遍；后者导致服务层“太胖”，复用性较差甚至无法复用；

分层架构的优点之一就是简单、约束少，可以在很短时间内实现简单业务功能，入门门槛低。开发人员只需要面向UI设计相应数据库表结构，在封装相应CURD接口就能快速实现一个功能。这也是分层架构如此普及的原因之一。但是，在它带来便捷的同时，它也带来了一些不利的因素，其中之一就是开发人员缺乏对业务场景的深度理解，缺乏对该类问题的抽象思考。当再次遇到同类功能时，都需要这么重复做一遍。长此以往，重复的表结构/字段会很多，相似的代码模块也会很多，十分不利于系统的升级维护。

3.DDD

DDD（领域驱动设计）是用来解决系统复杂性的方法论。DDD是一套系统性的设计思想，它在战略设计层面上，提出了领域、子域、限界上下文，来指导将一个大系统拆分为多个子系统。它在战术设计层面上，提出了实体、值对象、聚合根、工厂、基础设施、领域服务、领域事件等概念，来指导领域模型的实现落地。它是一种抽象思想，并不是一种具体的架构。在业务落地实现时，开发人员需要深入思考领域知识和业务知识，找到各个层次的边界。同时，分层内每一层次间的命名应符合统一规范，层次之间的交互应遵从最少知识原则，保证分层的独立性，解耦依赖。在做领域模型设计时，领域内部要聚焦在这个域自身功能上，设计时重点思考领域应该具备的能力，而不是面向调用方。通过领域模型可以提升设计过程的规范，有助于提高开发人员的架构设计能力，提升系统的可读性、复用性和扩展性。

基于领域模式实现功能时，经常遇到的问题之一，是哪些逻辑应该放在领域内，如果把所有业务逻辑都放到领域内，那过度膨胀的领域就失去了领域自身表达的意义。我们在实践中，通常会先将业务逻辑拆分为原子的功能点和控制流程，将明确属于领域内的逻辑合并，将不明确的功能点放在应用层，在后续迭代中再根据业务来沉淀模型能力。

在分层设计实现中，我们需要将领域逻辑与业务场景流程控制分离。在领域层来实现核心业务功能，在应用层，通过流程控制聚合各个领域实现特定业务场景，同时在应用层实现不属于领域内的业务场景细节逻辑。流程控制方面需要结合业务，原则上以简洁实用为主，保证既能满足业务功能，又能保持扩展性和可读性。在我们业务中，大部分业务场景是基于领域能力组合实现，少部分业务场景我们引入了FSM(有限状态机)、轻量规则引擎、Pipeline模式等；

诚然DDD有很多优势，但是我们在实践和持续迭代过程中也遇到一些问题。最明显的问题是DDD对开发人员要求较高，需要开发人员对领域模型和业务知识有较深入的思考与理解，才能设计出符合领域规范的实现方案。在理解不充分时，会出现强行套概念现象，最终的实现往往会变成“四不像”，不仅不能合理表达领域的能力，而且还会因为未正确实现约束导致代码混乱。

4.适合当前业务的架构

在我们已有的微服务架构中，我们尝试着以一种更轻量级的领域设计来融合到微服务业务架构中。通过领域模式的核心思想，来管理业务域的核心逻辑，在概念上保留领域对象、基础设施、领域服务、领域事件，同时领域对象采用贫血模型，通过领域方法来描述领域能力，逻辑功能高度内聚。同时，在领域服务层，我们分离读和写，只有写服务依赖领域能力来实现核心的状态变更，读服务直接基于基础设施层来提供能力。这种模式下形成的架构如下：

通过这样的分层，我们在层次间的依赖上面，保持了足够的灵活性；而在核心的业务逻辑上，也具备领域能力的高度内聚，保证了一定的复用性和扩展性。同时，也降低了对开发人员的要求，让对领域模型理解不深的人员也能保证一定的完成质量。

5.总结

业务架构并没有所谓的通用方案，它跟业务形态，业务发展所处阶段息息相关，只有适合自身业务的架构才是最好的架构。

关于业务架构的一些思考与实践相关推荐

美团住宿业务数据治理体系化思考与实践
全网最全大数据面试提升手册! 一.序言二.背景介绍三.治理体系化思考 3.1 什么是数据治理体系化? 3.2 数据治理体系化如何解决目前治理存在的问题? 3.3 业务数据管治体系框架如何建设? 3 ...
企业文化、业务架构与中台：移植阿里的中台战略能成功吗？
导读:中台是当下非常火热的技术概念,尽管中台本身并非一个明确的定义,而更像一个比喻,就像钟华老师引述美军的"火力中台"来类比阿里的"业务中台"一样. 中台设计, ...
荐书丨企业业务架构的发展及与IT架构的关系
架构君:本文来自<企业级业务架构设计:方法论与实践>一书,作者为付晓岩,本书专注于企业级的业务架构,公众号「架构文摘」获得机械工业出版社华章分社的授权,刊载其中的部分章节--企业业务架构的 ...
企业业务架构的需求管理与软件开发的供求曲线
世事唯有变化不变,架构亦如此.企业架构因其庞大的体量,必然蕴含众多引致其变化的因素,即便是一个被仔细切分过的服务也很难保证自己不会变化,何况包罗万象的架构.架构设计并不是为了一味的追求稳定,甚至不是为 ...
基于企业级业务架构的需求管理与软件开发的供求曲线
世事唯有变化不变,架构亦如此.企业架构因其庞大的体量,必然蕴含众多引致其变化的因素,即便是一个被仔细切分过的服务也很难保证自己不会变化,何况包罗万象的架构.架构设计并不是为了一味的追求稳定,甚至不是为 ...
云原生架构下复杂工作负载混合调度的思考与实践
作者: 实验室小陈 / 大数据开放实验室 10月25日,第一届中国云计算基础架构开发者大会在长沙召开,星环科技与众多国内外厂商共同就"云原生"."安全与容错"和 ...
单体架构迁移到微服务，8个关键的思考、实践和经验
单体架构迁移到微服务,8个关键的思考.实践和经验转自:http://www.open-open.com/lib/view/open1470917801705.html 随着微服务架构的持续火热,网络 ...
IaaS首席架构师的架构设计思考与实践
摘要:本文分享了华为云Stack IaaS的设计思考与实践,基于公有云先进的架构技术和创新能力,采用重构改造+积木式搭配+抽屉式替换等方式,健康的.可持续的为客户不断的提供产品和服务. 本文分享自华为 ...
软件开发架构模式浅谈：一些思考和实践记录
一背景和问题我个人平时会比较慎用"架构"这个词一方面是觉得业界有很多架构大师和架构模式,而我的认知和实践有限: 另一方面是因为这个词看着挺高大上.有点务虚,如果不结合实际场景 ...

关于业务架构的一些思考与实践

关于业务架构的一些思考与实践相关推荐

最新文章

热门文章