共计 2152 个字符，预计需要花费 6 分钟才能阅读完成。
文 | 巴里
网易智企资深工程师
业务架构是什么？
随着业务的倒退，咱们面临的业务场景也越来越简单，而为了解决这些简单的业务问题，咱们的实现计划也越来越简单，而复杂度就会带来了解、保护、迭代的难度减少。摆在咱们背后的问题，就是如何在实现简单业务时，管制好零碎的复杂度。
业务架构的外围目标，是控制系统的复杂度。通过业务架构，来传递标准与束缚。疏导开发人员在实现业务性能时，进行正当的业务问题合成，结构化、抽象化设计，保证系统的可维护性与可读性，延缓零碎腐化速度。
分层架构
传统的三层架构分为体现层、业务逻辑层、数据拜访层，各层之间通过接口交互，通过 Model 来传递数据。
这种三层架构非常简单，根本没有开发门槛，往往实用于性能简略的单体利用。当业务较简单，对稳定性和扩展性有肯定要求时，咱们往往会采纳微服务分层架构。与传统的三层架构相比，微服务架构里将业务逻辑层拆分为两局部，一部分是针对业务场景的业务网关层，一部分是针对业务逻辑的业务服务层。咱们往往将逻辑性能放在业务服务层，实现业务的隔离与复用。
微服务分层架构能满足大多数业务，这也是咱们最常见的业务架构之一，然而它也仍然存在问题。业务网关层和业务服务层之间的边界，须要开发人员了解并恪守分层标准才行，然而理论开发过程中大家的了解不统一，常常会呈现所有逻辑实现都在业务网关层、业务服务层只提供数据，以及呈现所有逻辑实现都在业务服务层、业务网关层只提供调用入口景象。前者导致服务层“太瘦”，下层复用时相干业务逻辑须要从新实现一遍；后者导致服务层“太胖”，复用性较差甚至无奈复用；
分层架构的长处之一就是简略、束缚少，能够在很短时间内实现简略业务性能，入门门槛低。开发人员只须要面向 UI 设计相应数据库表构造，在封装相应 CURD 接口就能疾速实现一个性能。这也是分层架构如此遍及的起因之一。然而，在它带来便捷的同时，它也带来了一些不利的因素，其中之一就是开发人员 不足对业务场景的深度了解，不足对该类问题的形象思考。当再次遇到同类性能时，都须要这么反复做一遍。长此以往，反复的表构造 / 字段会很多，类似的代码模块也会很多，非常不利于零碎的降级保护。
畛域驱动设计
DDD（畛域驱动设计）是用来解决零碎复杂性的方法论。
DDD 是一套系统性的设计思维，它在策略设计层面上，提出了畛域、子域、限界上下文，来领导将一个大零碎拆分为多个子系统。它在战术设计层面上，提出了实体、值对象、聚合根、工厂、基础设施、畛域服务、畛域事件等概念，来领导畛域模型的实现落地。它是一种形象思维，并不是一种具体的架构 。在业务落地实现时，开发人员须要深刻思考畛域常识和业务知识，找到 各个档次的边界 。同时，分层内每一档次间的命名应合乎对立标准，档次之间的交互应听从起码常识准则，保障分层的独立性，解耦依赖。在做畛域模型设计时， 畛域外部要聚焦在这个域本身性能上，设计时重点思考畛域应该具备的能力，而不是面向调用方。
通过畛域模型能够晋升设计过程的标准，有助于进步开发人员的架构设计能力，晋升零碎的可读性、复用性和扩展性。
基于畛域模式实现性能时，常常遇到的问题之一，是哪些逻辑应该放在畛域内，如果把所有业务逻辑都放到畛域内，那适度收缩的畛域就失去了畛域本身表白的意义。咱们在实践中，通常会先将业务逻辑拆分为原子的性能点和管制流程，将明确属于畛域内的逻辑合并，将不明确的性能点放在应用层，在后续迭代中再依据业务来积淀模型能力。
在分层设计实现中，咱们须要 将畛域逻辑与业务场景流程管制拆散。在畛域层来实现外围业务性能，在应用层，通过流程管制聚合各个领域实现特定业务场景，同时在应用层实现不属于畛域内的业务场景细节逻辑。流程管制方面须要联合业务，原则上以简洁实用为主，保障既能满足业务性能，又能放弃扩展性和可读性。在咱们业务中，大部分业务场景是基于畛域能力组合实现，少部分业务场景咱们引入了 FSM(无限状态机)、轻量规定引擎、Pipeline 模式等；
诚然 DDD 有很多劣势，然而咱们在实际和继续迭代过程中也遇到一些问题。最显著的问题是 DDD 对开发人员要求较高，须要开发人员对畛域模型和业务知识有较深刻的思考与了解，能力设计出合乎畛域标准的实现计划。在了解不充沛时，会呈现强行套概念景象，最终的实现往往会变成“四不像”，不仅不能正当表白畛域的能力，而且还会因为未正确实现束缚导致代码凌乱。
适宜以后业务的架构
在咱们已有的微服务架构中，咱们尝试着以一种更轻量级的畛域设计来交融到微服务业务架构中。通过畛域模式的核心思想，来治理业务域的外围逻辑，在概念上保留畛域对象、基础设施、畛域服务、畛域事件，同时畛域对象采纳贫血模型，通过畛域办法来形容畛域能力，逻辑性能高度内聚。同时，在畛域服务层，咱们拆散读和写，只有写服务依赖畛域能力来实现外围的状态变更，读服务间接基于基础设施层来提供能力。这种模式下造成的架构如下：
通过这样的分层，咱们在档次间的依赖下面，放弃了足够的灵活性；而在外围的业务逻辑上，也具备畛域能力的高度内聚，保障了肯定的复用性和扩展性。同时，也升高了对开发人员的要求，让对畛域模型了解不深的人员也能保障肯定的实现品质。
总结
业务架构并没有所谓的通用计划，它跟业务状态，业务倒退所处阶段非亲非故，只有适宜本身业务的架构才是最好的架构。
