传统分层架构改造方案咨询：可行性与命名（非洋葱架构）

项目背景与改进思路 #

我们有一个核心传统分层项目，架构为UI → BL → Data，其他项目均依赖它。但因缺少接口设计，各方按需修改代码引发了诸多问题。有人提议采用洋葱架构，但我有两点顾虑：

• 项目以DB和ADO.NET为核心，短期内无变更计划，无需额外抽象
• 多数为CRUD操作，Domain Services与App Services会增加复杂度

为此我提出以下改进方案：

• 引入Event Bus，方便中途扩展逻辑
• 不完全实现洋葱架构，设置如下分层：
  • Domain：包含DB实体（DB Entities）及数据访问接口（Interfaces for DA）
  • Application：包含服务接口（Interfaces for Services）、数据传输对象（DTOs）及服务实现（Services）
  • Infrastructure：实现数据访问层（DA）
  • Presentation：包含Api控制器、MVC控制器以及继承自DTOs的视图模型（View Models）
  • IoC：依赖注入配置

请问该方案是否可行？应如何命名？

方案可行性分析 #

你的方案完全可行，且精准贴合当前项目的实际场景：

1. 接口解耦直击痛点：通过在Domain层定义DA接口、Application层定义服务接口，彻底解决了原项目无接口导致的随意修改核心代码问题；同时没有过度抽象——保留ADO.NET核心地位的前提下，用接口隔离了依赖方向，后续若需替换数据源也预留了扩展空间。
2. 适配CRUD场景：没有强行引入冗余的Domain Services，而是将服务逻辑放在Application层，既满足了CRUD操作的简洁性，又通过接口保证了代码的可维护性。
3. Event Bus的适配性：对于CRUD为主的项目，Event Bus可以在不改动核心CRUD代码的前提下，快速扩展日志、通知、数据同步等附加逻辑，完美匹配“中途扩展”的需求。
4. 分层逻辑务实：当前分层既借鉴了洋葱架构的依赖倒置思想（核心层不依赖外层），又避免了其在简单CRUD场景下的冗余，是一种务实的简化版架构。

架构命名建议 #

可以从两个方向选择命名，贴合项目特点：

务实型命名 #

• 简化版洋葱架构（ADO.NET适配）：直接点明是洋葱架构的简化变体，同时突出对ADO.NET的适配，让团队快速理解架构定位。
• 接口驱动型传统分层架构：强调核心改进是加入接口解耦，同时保留传统分层的熟悉感，适合团队平稳过渡。

具象化命名 #

• 核心业务分层架构（CBLA, Core Business Layered Architecture）：突出项目作为核心依赖的地位，同时明确是分层架构的属性。
• CRUD友好型接口分层架构：直接点明架构对CRUD场景的优化，以及核心特性是接口驱动。

内容的提问来源于stack exchange，提问作者Ahmed Galal