1.业务架构是什么
随着业务的发展，我们面临的业务场景也越来越复杂，而为了解决这些复杂的业务问题，我们的实现方案也越来越复杂，而复杂度就会带来理解、维护、迭代的难度增加。摆在我们面前的问题，就是如何在实现复杂业务时，控制好系统的复杂度。
业务架构的核心目的，是控制系统的复杂度。通过业务架构，来传递规范与约束。引导开发人员在实现业务功能时，进行合理的业务问题分解，结构化、抽象化设计，保证系统的可维护性与可读性，延缓系统腐化速度。
2.分层架构
传统的三层架构分为表现层、业务逻辑层、数据访问层，各层之间通过接口交互，通过Model来传递数据。这种三层架构非常简单，基本没有开发门槛，往往适用于功能简单的单体应用。当业务较复杂，对稳定性和扩展性有一定要求时，我们往往会采用微服务分层架构。与传统的三层架构相比，微服务架构里将业务逻辑层拆分为两部分，一部分是针对业务场景的业务网关层，一部分是针对业务逻辑的业务服务层。我们往往将逻辑功能放在业务服务层，实现业务的隔离与复用。
微服务分层架构能满足大多数业务，这也是我们最常见的业务架构之一，但是它也依然存在问题。业务网关层和业务服务层之间的边界，需要开发人员理解并遵守分层规范才行，但是实际开发过程中大家的理解不一致，经常会出现所有逻辑实现都在业务网关层、业务服务层只提供数据，以及出现所有逻辑实现都在业务服务层、业务网关层只提供调用入口现象。前者导致服务层“太瘦”，上层复用时相关业务逻辑需要重新实现一遍；后者导致服务层“太胖”，复用性较差甚至无法复用；
分层架构的优点之一就是简单、约束少，可以在很短时间内实现简单业务功能，入门门槛低。开发人员只需要面向UI设计相应数据库表结构，在封装相应CURD接口就能快速实现一个功能。这也是分层架构如此普及的原因之一。但是，在它带来便捷的同时，它也带来了一些不利的因素，其中之一就是开发人员缺乏对业务场景的深度理解，缺乏对该类问题的抽象思考。当再次遇到同类功能时，都需要这么重复做一遍。长此以往，重复的表结构/字段会很多，相似的代码模块也会很多，十分不利于系统的升级维护。
3.DDD
DDD（领域驱动设计）是用来解决系统复杂性的方法论。DDD是一套系统性的设计思想，它在战略设计层面上，提出了领域、子域、限界上下文，来指导将一个大系统拆分为多个子系统。它在战术设计层面上，提出了实体、值对象、聚合根、工厂、基础设施、领域服务、领域事件等概念，来指导领域模型的实现落地。它是一种抽象思想，并不是一种具体的架构。在业务落地实现时，开发人员需要深入思考领域知识和业务知识，找到各个层次的边界。同时，分层内每一层次间的命名应符合统一规范，层次之间的交互应遵从最少知识原则，保证分层的独立性，解耦依赖。在做领域模型设计时，领域内部要聚焦在这个域自身功能上，设计时重点思考领域应该具备的能力，而不是面向调用方。通过领域模型可以提升设计过程的规范，有助于提高开发人员的架构设计能力，提升系统的可读性、复用性和扩展性。
基于领域模式实现功能时，经常遇到的问题之一，是哪些逻辑应该放在领域内，如果把所有业务逻辑都放到领域内，那过度膨胀的领域就失去了领域自身表达的意义。我们在实践中，通常会先将业务逻辑拆分为原子的功能点和控制流程，将明确属于领域内的逻辑合并，将不明确的功能点放在应用层，在后续迭代中再根据业务来沉淀模型能力。
在分层设计实现中，我们需要将领域逻辑与业务场景流程控制分离。在领域层来实现核心业务功能，在应用层，通过流程控制聚合各个领域实现特定业务场景，同时在应用层实现不属于领域内的业务场景细节逻辑。流程控制方面需要结合业务，原则上以简洁实用为主，保证既能满足业务功能，又能保持扩展性和可读性。在我们业务中，大部分业务场景是基于领域能力组合实现，少部分业务场景我们引入了FSM(有限状态机)、轻量规则引擎、Pipeline模式等；
诚然DDD有很多优势，但是我们在实践和持续迭代过程中也遇到一些问题。最明显的问题是DDD对开发人员要求较高，需要开发人员对领域模型和业务知识有较深入的思考与理解，才能设计出符合领域规范的实现方案。在理解不充分时，会出现强行套概念现象，最终的实现往往会变成“四不像”，不仅不能合理表达领域的能力，而且还会因为未正确实现约束导致代码混乱。
4.适合当前业务的架构
在我们已有的微服务架构中，我们尝试着以一种更轻量级的领域设计来融合到微服务业务架构中。通过领域模式的核心思想，来管理业务域的核心逻辑，在概念上保留领域对象、基础设施、领域服务、领域事件，同时领域对象采用贫血模型，通过领域方法来描述领域能力，逻辑功能高度内聚。同时，在领域服务层，我们分离读和写，只有写服务依赖领域能力来实现核心的状态变更，读服务直接基于基础设施层来提供能力。这种模式下形成的架构如下：
通过这样的分层，我们在层次间的依赖上面，保持了足够的灵活性；而在核心的业务逻辑上，也具备领域能力的高度内聚，保证了一定的复用性和扩展性。同时，也降低了对开发人员的要求，让对领域模型理解不深的人员也能保证一定的完成质量。
5.总结
业务架构并没有所谓的通用方案，它跟业务形态，业务发展所处阶段息息相关，只有适合自身业务的架构才是最好的架构。
