尖叫架构是由著名软件开发人员和思想领袖 robert c. martin(通常被称为“bob 叔叔”)提出的概念。这个术语可能听起来非常规,但它代表了软件设计中的一个强大原则,专注于使系统架构反映应用程序的主要关注点和用例。简而言之,您的软件架构应该“尖叫”其意图和目的。
在这份综合指南中,我们将探讨 screaming architecture 的基础知识、它与传统软件架构的对比、它在领域驱动设计中的重要性,以及如何在项目中实现此架构。我们还将介绍 screaming architecture 可以提高代码可读性、可维护性和长期可扩展性的实际示例和场景。
为什么要“尖叫”建筑?
尖叫架构背后的想法是代码库的主要结构应该立即传达其业务目的。这与传统架构形成鲜明对比,传统架构可能强调技术框架、工具或其他次要问题。在尖叫架构中,领域关注优先于实现细节。
鲍勃·马丁叔叔用一个类比来说明这一点:想象一下走到一座建筑物前,看看它的建筑。无需标志,您通常就能辨别出这是图书馆、学校还是办公室。这同样适用于软件架构。当您查看应用程序的文件夹结构和设计时,您应该立即了解它的用途。如果你正在构建一个会计系统,架构应该大喊“会计”,而不是“django”、“spring boot”或“react”。
以框架为中心的架构的问题
在许多项目中,对技术框架的关注掩盖了业务或领域逻辑。您会发现如下文件结构:
controllers/ services/ repositories/ models/
虽然这些目录很有用,但它们描述了技术角色,而不是反映软件解决的核心问题。例如,此结构告诉您系统使用 mvc(模型-视图-控制器),但没有深入了解系统是否处理财务数据、用户管理或内容创建。
框架陷阱
过度强调框架会导致代码库中的业务逻辑被技术样板所掩盖。围绕框架约定构建的系统与这些框架紧密耦合。如果你想改变框架或技术栈,重构就成为一项主要工作。 screaming architecture 提倡保持领域逻辑干净且独立,因此框架的选择成为实现细节,而不是代码库的核心结构。
领域驱动设计 (ddd) 中令人惊叹的架构
领域驱动设计(ddd)和尖叫架构经常齐头并进。 ddd 是一种强调技术和领域专家之间协作的软件开发方法,它侧重于以与实际操作紧密结合的方式对核心业务逻辑进行建模。
在 screaming architecture 中,领域模型和业务逻辑位于应用程序的中心,而其他所有内容(框架、数据库、ui 和服务)都变成了外围。关键思想是代码结构应该反映领域模型而不是技术实现细节。
以下是如何使用领域驱动原则以“尖叫”其意图的方式构建项目:
/src /accounting ledger.cs transaction.cs account.cs taxservice.cs /sales order.cs invoice.cs customer.cs discountpolicy.cs
在此示例中,文件夹名称直接反映了业务问题:会计和销售。每个特定于域的类,如 ledger、transaction 和 order,都放置在其相关的域上下文中。这种结构可以立即清楚系统的含义以及每个组件的适用位置。
代码示例 1:简单的以领域为中心的结构
考虑一个处理订单和库存的电子商务应用程序。使用 screaming architecture,文件夹结构应该反映业务逻辑而不是技术角色:
/src /orders order.cs orderservice.cs orderrepository.cs /inventory inventoryitem.cs inventoryservice.cs inventoryrepository.cs
这是订单上下文中的基本代码示例:
public class order { public guid id { get; set; } public datetime orderdate { get; set; } public list<orderitem> items { get; set; } public decimal totalamount { get; set; } public order(list<orderitem> items) { id = guid.newguid(); orderdate = datetime.now; items = items; totalamount = calculatetotal(items); } private decimal calculatetotal(list<orderitem> items) { return items.sum(item => item.price * item.quantity); } } public class orderitem { public string productname { get; set; } public decimal price { get; set; } public int quantity { get; set; } } </orderitem></orderitem></orderitem>
在此代码中,域概念(订单)位于前端和中心,orderservice 和 orderrepository 等支持逻辑保存在单独的文件中。业务逻辑 (calculatetotal) 是 order 实体的一部分,而不是隐藏在服务或控制器中。
避免技术干扰
框架和库对于软件开发至关重要,但它们不应该决定您的业务逻辑的结构。 screaming architecture 主张将 http 控制器、持久层和数据库框架等技术细节推向外围。
这是一个对比传统架构和尖叫架构的例子:
传统建筑:
/src /controllers ordercontroller.cs /services orderservice.cs /repositories orderrepository.cs /models order.cs orderitem.cs
虽然这在技术上是正确的,但它并没有告诉您该系统的用途。文件夹结构没有透露任何有关域的信息。这是一个电子商务系统吗?金融应用程序?如果不深入代码,就不可能知道。
尖叫建筑:
/src /orders ordercontroller.cs orderservice.cs orderrepository.cs order.cs orderitem.cs /inventory inventorycontroller.cs inventoryservice.cs inventoryrepository.cs inventoryitem.cs
这个结构立即阐明了系统处理订单和库存。如果您将来添加更多域(例如客户、付款),它们将在架构中拥有专用位置。
清洁架构的作用
尖叫架构通常与鲍勃叔叔更广泛的清洁架构原则保持一致。清洁架构提倡关注点分离,重点关注确保业务规则独立于框架、ui 和数据库。尖叫架构更进一步,建议项目的结构应该揭示核心业务逻辑。
这是清洁架构的快速回顾:
实体:核心业务对象和逻辑。
用例:特定于应用程序的业务规则。
接口:框架和外部系统的网关。
框架和驱动程序:ui、数据库和其他外部组件。
在清洁架构项目中,订单、客户和发票等领域概念是中心层的一部分。 asp.net core、django 或 rails 等框架被归入外层,充当提供核心功能的机制。
代码示例 2:在 screaming architecture 中应用清洁架构
在尖叫架构中,您将以反映业务领域的方式构建用例和实体。让我们扩展我们的电子商务示例:
/src /orders createorderusecase.cs orderrepository.cs order.cs orderitem.cs /inventory addinventoryitemusecase.cs inventoryrepository.cs inventoryitem.cs
这是创建订单的示例用例:
public class CreateOrderUseCase { private readonly IOrderRepository _orderRepository; private readonly IInventoryService _inventoryService; public CreateOrderUseCase(IOrderRepository orderRepository, IInventoryService inventoryService) { _orderRepository = orderRepository; _inventoryService = inventoryService; } public Order Execute(List<orderitem> items) { // Ensure all items are available in inventory foreach (var item in items) { _inventoryService.CheckInventory(item.ProductName, item.Quantity); } var order = new Order(items); _orderRepository.Save(order); return order; } } </orderitem>
在此示例中,createorderusecase 是域逻辑的一部分,它与 orderrepository 和 inventoryservice 交互,以满足创建订单的业务需求。
尖叫建筑的好处
提高可读性:任何打开代码库的人都会立即了解系统的功能。
关注点分离:业务逻辑与技术细节保持隔离,使得以后更容易更改框架或技术。
可扩展性:随着系统的增长,域结构保持一致,允许轻松添加新功能和模块。
可维护性:当领域逻辑与外部依赖项和框架完全分离时,它更容易维护。
与框架无关:screaming architecture 允许业务逻辑在不同的技术堆栈之间保持可移植性,避免与任何特定框架的紧密耦合。
对尖叫建筑的批评
虽然尖叫建筑有很多好处,但它也并非没有批评:
感知的复杂性:不熟悉领域驱动设计的开发人员可能会发现,对于小型应用程序来说,将领域逻辑与技术细节分离是不必要的或过于复杂。
2
。开销:在小型项目或简单的 crud 应用程序中,实现 screaming architecture 可能看起来有点矫枉过正。
学习曲线:对于习惯框架优先方法的团队来说,采用 screaming 架构需要转变思维,这可能需要时间来内化。
何时使用尖叫架构
尖叫架构在以下场景中特别有用:
领域驱动系统:具有复杂业务规则和领域逻辑的应用程序。
长期项目:系统预计会随着时间的推移而发展,其中可扩展性和可维护性至关重要。
跨平台开发:可以切换框架或平台的系统,因此业务逻辑的清晰分离至关重要。
结论
尖叫建筑不仅仅是一个朗朗上口的名字;这是一种主张使核心业务逻辑成为代码库中最突出的部分的哲学。通过关注领域概念而不是技术框架,开发人员可以构建从长远来看更具可读性、可维护性和可扩展性的系统。无论您是在开发简单的 web 应用程序还是复杂的企业系统,采用 screaming architecture 都可以生成更清晰、更集中的代码,清楚地表达其目的。
要了解有关尖叫建筑的更多信息,您可以查看一些参考资料和附加读物:
罗伯特·c.马丁的干净建筑
eric evans 的领域驱动设计
鲍勃叔叔关于干净代码的博客
通过采用尖叫架构的原则,您可以创建不仅可以工作而且可以“尖叫”其意图的代码库。