1. 项目概述从“一团乱麻”到“井然有序”的代码进化论干了这么多年开发最怕接手什么样的代码不是技术栈老旧的也不是逻辑复杂的而是那种一个文件几千行、所有功能都揉在一起、改一处而动全身的“意大利面条式”代码。这种代码就像一间塞满杂物的房间想找把螺丝刀得先挪开一堆旧报纸、踢开几个空箱子最后发现它被压在了一摞书下面。每次维护都像一次考古发掘小心翼翼生怕碰倒了哪根“承重柱”导致整个系统崩溃。我们今天要聊的“应用面向对象编程SoC原则的典型示例”就是解决这个问题的核心方法论和实战指南。SoC即关注点分离它不是某个具体框架或语法糖而是一种深刻的设计哲学其核心思想是将复杂的系统分解为多个独立的、功能内聚的部分每个部分只负责一个特定的关注点并通过定义良好的接口进行通信。简单来说SoC原则就是让代码“各司其职”。想象一下一个餐厅的后厨如果让一位厨师既负责切菜、又负责炒菜、还负责摆盘和洗碗那么出餐效率必然低下且一旦这位厨师请假整个厨房就瘫痪了。一个遵循SoC原则的后厨会有专门的切配工、炉头师傅、打荷和洗碗工每个人职责明确通过传菜口这个“接口”协作整个系统高效且健壮。在软件中这个“切配工”可能就是数据访问层“炉头师傅”是业务逻辑层“打荷”则是表现层。应用SoC原则能直接带来几个好处提升代码可读性与可维护性因为逻辑被清晰地划分增强代码的可测试性每个模块可以独立进行单元测试提高开发团队的协作效率不同开发者可以并行开发不同模块而互不干扰提升系统的可扩展性需要新增功能时往往只需修改或新增特定模块而不必重构整个系统。接下来我将通过一个从“混沌”到“清晰”的完整重构案例拆解SoC原则如何落地。这个案例模拟一个简单的“用户订单管理系统”我们将看到它如何从一个所有代码都堆在同一个类中的“上帝类”逐步演变为一个层次清晰、职责分明的优雅架构。无论你是刚入门希望建立良好编码习惯的新手还是有一定经验但时常感到代码难以驾驭的中级开发者这篇内容都将为你提供一套可直接套用的设计思路和实操模板。2. 核心架构与设计思路拆解2.1 问题起点一个典型的“反模式”代码库在展示优雅方案前我们必须先认清问题。下面是一段未应用SoC原则的OrderProcessor类代码片段它试图处理用户下单的全流程public class OrderProcessor { // 反例所有关注点混杂在一个类中 public void processOrder(String userId, ListString productIds) { // 关注点1: 数据验证 if (userId null || userId.isEmpty()) { System.out.println(用户ID不能为空); return; } for (String pid : productIds) { if (pid null || pid.isEmpty()) { System.out.println(商品ID不能为空); return; } } // 关注点2: 数据库操作用户信息 Connection conn null; PreparedStatement stmt null; ResultSet rs null; try { conn DriverManager.getConnection(jdbc:mysql://localhost:3306/shop, root, password); stmt conn.prepareStatement(SELECT * FROM users WHERE id ?); stmt.setString(1, userId); rs stmt.executeQuery(); if (!rs.next()) { System.out.println(用户不存在); return; } String userName rs.getString(name); // ... 关闭资源代码略 // 关注点3: 数据库操作商品信息与库存 conn DriverManager.getConnection(...); stmt conn.prepareStatement(SELECT price, stock FROM products WHERE id ?); double totalAmount 0.0; for (String pid : productIds) { stmt.setString(1, pid); rs stmt.executeQuery(); if (rs.next()) { double price rs.getDouble(price); int stock rs.getInt(stock); if (stock 0) { System.out.println(商品 pid 库存不足); return; } totalAmount price; // 关注点4: 业务逻辑扣减库存 PreparedStatement updateStmt conn.prepareStatement(UPDATE products SET stock stock - 1 WHERE id ?); updateStmt.setString(1, pid); updateStmt.executeUpdate(); } } // 关注点5: 数据库操作创建订单 String orderId ORD System.currentTimeMillis(); stmt conn.prepareStatement(INSERT INTO orders (id, user_id, amount, status) VALUES (?, ?, ?, CREATED)); stmt.setString(1, orderId); stmt.setString(2, userId); stmt.setDouble(3, totalAmount); stmt.executeUpdate(); // 关注点6: 外部服务调用支付 boolean paymentSuccess callPaymentGateway(userId, totalAmount); if (!paymentSuccess) { System.out.println(支付失败订单已创建但未支付); // 可能需要回滚订单这里逻辑复杂了... return; } // 关注点7: 数据库操作更新订单状态 stmt conn.prepareStatement(UPDATE orders SET status PAID WHERE id ?); stmt.setString(1, orderId); stmt.executeUpdate(); // 关注点8: 通知邮件发送 sendEmail(userName, orderId, totalAmount); System.out.println(订单处理成功); } catch (SQLException e) { System.out.println(数据库错误: e.getMessage()); } finally { // ... 繁琐的资源关闭代码 } } private boolean callPaymentGateway(String userId, double amount) { // 模拟调用支付接口 System.out.println(调用支付网关用户 userId 金额 amount); return Math.random() 0.1; // 模拟90%成功率 } private void sendEmail(String userName, String orderId, double amount) { // 模拟发送邮件 System.out.println(发送邮件给 userName 订单号 orderId 金额 amount); } }这段代码就是一个典型的“反面教材”。它至少混杂了8个不同的关注点输入验证、用户数据存取、商品数据存取与库存检查、库存扣减业务逻辑、订单数据持久化、支付网关调用、订单状态更新、邮件通知。所有这些问题集中在一个方法里导致难以阅读和维护任何一个功能的修改都需要深入这个庞大的方法。无法独立测试你想测试支付逻辑却必须连接真实数据库、调用真实邮件服务。代码复用性为零发送邮件的逻辑无法被其他业务流程使用。职责不清牵一发而动全身修改数据库连接方式会影响所有逻辑。2.2 SoC分层架构设计构建清晰的边界为了解决上述问题我们引入经典的三层架构作为SoC原则的落地形式。三层架构将系统横向切分为三个主要层次每层有且仅有一个核心职责表现层 (Presentation Layer)负责处理用户交互。它接收用户的输入如HTTP请求、命令行参数将其转换为对业务逻辑层的调用并将业务逻辑层返回的结果以合适的形式如HTML页面、JSON数据呈现给用户。它不包含任何业务规则或数据访问逻辑。在我们的例子中可以是一个简单的控制台菜单也可以是一个Spring MVC的Controller。业务逻辑层 (Business Logic Layer)这是系统的核心。它包含具体的业务规则、流程控制和领域模型。例如“下单前必须检查库存”、“支付成功后更新订单状态并发送通知”这些规则就在这里实现。它依赖于数据访问层获取数据但完全不知道数据来自数据库还是文件。它应该是“纯净”的业务逻辑。数据访问层 (Data Access Layer)负责与数据源通常是数据库打交道。它封装了所有创建、读取、更新、删除CRUD操作。业务逻辑层通过接口调用它从而与具体的数据存储技术MySQL、MongoDB、Redis解耦。这意味着未来更换数据库理论上只需重写数据访问层的实现而业务逻辑层无需改动。此外我们常常会抽象出服务层 (Service Layer)位于业务逻辑层中用于协调多个领域对象或数据访问对象来完成一个完整的业务用例如“处理订单”。还会引入领域模型 (Domain Model)如User、Product、Order等类它们是业务概念的载体包含数据和基本行为。这个分层架构的核心价值在于依赖方向表现层依赖业务逻辑层业务逻辑层依赖数据访问层。这种单向依赖通过依赖注入等技术实现确保了高层模块不依赖于低层模块的具体实现两者都依赖于抽象接口。3. 重构实战一步步实现关注点分离现在我们开始对那个“一团糟”的OrderProcessor进行外科手术式的重构。3.1 第一步定义清晰的领域模型首先将业务中核心的名词抽象成类这是分离数据实体的关注点。// 领域模型User.java public class User { private String id; private String name; private String email; // 构造方法、getter、setter 省略 } // 领域模型Product.java public class Product { private String id; private String name; private double price; private int stock; // 构造方法、getter、setter 省略 // 可以包含简单的领域行为如扣减库存 public void reduceStock(int quantity) { if (this.stock quantity) { throw new IllegalArgumentException(库存不足); } this.stock - quantity; } } // 领域模型Order.java public class Order { private String id; private String userId; private ListOrderItem items; private double totalAmount; private String status; // CREATED, PAID, SHIPPED等 private LocalDateTime createTime; // 构造方法、getter、setter 省略 // 领域行为计算总价这里简化实际可能更复杂 public void calculateTotal() { this.totalAmount items.stream().mapToDouble(OrderItem::getSubTotal).sum(); } }注意领域模型应该是“贫血”还是“富血”一直有争议。我个人倾向于在模型中加入与自身数据紧密相关的、不涉及外部依赖的简单行为如Product.reduceStock而将涉及多个实体协作或外部服务的复杂逻辑放在服务层。这本身也是一种关注点分离。3.2 第二步构建数据访问层Repository为每个主要的领域模型创建数据访问接口及其实现将数据库操作的关注点隔离出来。// 数据访问层接口UserRepository.java public interface UserRepository { User findById(String userId); void save(User user); } // 数据访问层接口ProductRepository.java public interface ProductRepository { Product findById(String productId); void save(Product product); } // 数据访问层接口OrderRepository.java public interface OrderRepository { void save(Order order); Order findById(String orderId); void updateStatus(String orderId, String status); }接着是接口的实现。这里以JdbcUserRepository为例展示如何将JDBC细节封装在内// 数据访问层实现JdbcUserRepository.java public class JdbcUserRepository implements UserRepository { private DataSource dataSource; // 通过依赖注入获得 public JdbcUserRepository(DataSource dataSource) { this.dataSource dataSource; } Override public User findById(String userId) { String sql SELECT id, name, email FROM users WHERE id ?; try (Connection conn dataSource.getConnection(); PreparedStatement stmt conn.prepareStatement(sql)) { stmt.setString(1, userId); ResultSet rs stmt.executeQuery(); if (rs.next()) { return new User(rs.getString(id), rs.getString(name), rs.getString(email)); } return null; } catch (SQLException e) { throw new DataAccessException(查询用户失败, e); // 抛出自定义运行时异常 } // 资源自动关闭代码更简洁 } Override public void save(User user) { // 实现插入或更新逻辑 } }实操心得在DAO/Repository实现中使用try-with-resources语句管理ConnectionStatementResultSet等资源可以避免繁琐的finally块和资源泄漏问题。同时将底层的SQLException转换为自定义的、非受检的DataAccessException可以避免业务层代码被特定的技术异常污染这符合SoC原则。3.3 第三步实现核心业务逻辑层Service业务逻辑层是SoC原则体现最明显的地方。我们创建OrderService来承载“处理订单”这个核心用例。// 业务逻辑层OrderService.java public class OrderService { // 依赖抽象而非具体实现 private final UserRepository userRepository; private final ProductRepository productRepository; private final OrderRepository orderRepository; private final PaymentService paymentService; private final NotificationService notificationService; // 通过构造函数注入依赖 public OrderService(UserRepository userRepo, ProductRepository productRepo, OrderRepository orderRepo, PaymentService paymentService, NotificationService notificationService) { this.userRepository userRepo; this.productRepository productRepo; this.orderRepository orderRepo; this.paymentService paymentService; this.notificationService notificationService; } /** * 处理订单 - 核心业务方法 * param userId 用户ID * param productIds 商品ID列表 * return 生成的订单ID * throws BusinessException 业务异常如库存不足、用户不存在 */ public String processOrder(String userId, ListString productIds) throws BusinessException { // 1. 参数验证简单的验证可以放在Service入口 validateInput(userId, productIds); // 2. 获取用户信息依赖数据访问层 User user userRepository.findById(userId); if (user null) { throw new BusinessException(用户不存在: userId); } // 3. 获取商品信息并检查库存业务规则 ListProduct products new ArrayList(); double totalAmount 0.0; for (String pid : productIds) { Product product productRepository.findById(pid); if (product null) { throw new BusinessException(商品不存在: pid); } if (product.getStock() 0) { throw new BusinessException(商品库存不足: product.getName()); } products.add(product); totalAmount product.getPrice(); // 注意这里只是计算尚未实际扣减库存 } // 4. 创建订单对象领域模型 Order order new Order(); order.setId(generateOrderId()); order.setUserId(userId); order.setStatus(CREATED); order.setTotalAmount(totalAmount); order.setCreateTime(LocalDateTime.now()); // 此处应构建OrderItem列表为简化省略 // 5. 调用支付服务依赖外部服务层 boolean paymentSuccess paymentService.charge(user, totalAmount); if (!paymentSuccess) { throw new BusinessException(支付失败); } // 6. 扣减库存并保存订单涉及数据变更应考虑事务 // 重要此处存在业务一致性风险见下文分析 for (Product product : products) { product.reduceStock(1); // 调用领域行为 productRepository.save(product); // 更新库存 } order.setStatus(PAID); orderRepository.save(order); // 7. 发送通知依赖外部服务层 notificationService.sendOrderConfirmation(user, order); return order.getId(); } private void validateInput(String userId, ListString productIds) { // 简单的非空、格式验证 if (userId null || userId.trim().isEmpty()) { throw new IllegalArgumentException(用户ID无效); } if (productIds null || productIds.isEmpty()) { throw new IllegalArgumentException(商品列表不能为空); } } private String generateOrderId() { return ORD System.currentTimeMillis() ThreadLocalRandom.current().nextInt(1000); } }这个OrderService的processOrder方法清晰地勾勒出了下单的业务流程。它不再关心数据如何从数据库取出那是Repository的事也不关心支付请求如何发送那是PaymentService的事更不关心邮件模板如何渲染那是NotificationService的事。它的关注点纯粹是业务流程的编排和业务规则的执行。3.4 第四步抽象外部服务与工具层将支付、通知等外部系统交互进一步分离。// 外部服务抽象PaymentService.java public interface PaymentService { boolean charge(User user, double amount); } // 实现某支付网关的实现 public class StripePaymentService implements PaymentService { private StripeClient stripeClient; Override public boolean charge(User user, double amount) { // 调用Stripe API的具体逻辑 // 返回支付结果 } } // 通知服务抽象NotificationService.java public interface NotificationService { void sendOrderConfirmation(User user, Order order); } // 实现邮件通知 public class EmailNotificationService implements NotificationService { private EmailSender emailSender; Override public void sendOrderConfirmation(User user, Order order) { String content 尊敬的 user.getName() 您的订单 order.getId() 已支付成功。; emailSender.send(user.getEmail(), 订单确认, content); } }3.5 第五步组装与表现层调用最后在应用入口如Spring Boot的RestController或一个简单的Main类中将所有组件像搭积木一样组装起来。// 表现层OrderController.java (以Spring MVC为例) RestController RequestMapping(/api/orders) public class OrderController { private final OrderService orderService; // Spring会自动注入OrderService public OrderController(OrderService orderService) { this.orderService orderService; } PostMapping public ResponseEntityOrderResponse createOrder(RequestBody CreateOrderRequest request) { // 表现层职责参数转换、调用服务、处理异常、返回标准响应 try { String orderId orderService.processOrder(request.getUserId(), request.getProductIds()); OrderResponse response new OrderResponse(orderId, 订单创建成功); return ResponseEntity.ok(response); } catch (BusinessException e) { // 捕获业务异常返回友好的错误信息 return ResponseEntity.badRequest().body(new OrderResponse(null, e.getMessage())); } catch (Exception e) { // 捕获系统异常记录日志返回通用错误 return ResponseEntity.status(500).body(new OrderResponse(null, 系统内部错误)); } } } // 一个简单的组装示例非Spring环境 public class Application { public static void main(String[] args) { // 1. 创建并组装所有组件 DataSource dataSource createDataSource(); UserRepository userRepo new JdbcUserRepository(dataSource); ProductRepository productRepo new JdbcProductRepository(dataSource); OrderRepository orderRepo new JdbcOrderRepository(dataSource); PaymentService paymentService new MockPaymentService(); // 模拟支付 NotificationService notificationService new ConsoleNotificationService(); // 控制台通知 OrderService orderService new OrderService(userRepo, productRepo, orderRepo, paymentService, notificationService); // 2. 模拟表现层调用 try { String orderId orderService.processOrder(user123, Arrays.asList(prod1, prod2)); System.out.println(成功创建订单: orderId); } catch (BusinessException e) { System.out.println(业务失败: e.getMessage()); } } }至此我们完成了一次完整的SoC重构。最初的“上帝类”被拆分为多个领域模型数据与简单行为、多个Repository数据访问、一个核心Service业务逻辑、多个外部服务支付、通知以及一个Controller用户交互。每个类的职责都变得单一而明确。4. 深入原理SoC原则的多种实现模式与权衡SoC原则不仅体现在分层架构上在更细的粒度上有多种经典的设计模式可以帮助我们实现它。4.1 MVC模式表现层内部的SoC在Web开发中MVC是SoC原则在表现层的直接体现。Model负责封装数据和业务逻辑通常对应我们的Service和DomainView负责展示数据Controller负责接收用户输入并协调Model和View。它们各司其职共同构成了清晰的表现层结构。4.2 领域驱动设计复杂业务下的SoC升华对于业务极其复杂的系统三层架构可能不够用。领域驱动设计通过引入聚合根、实体、值对象、领域服务、仓储、领域事件等概念在业务逻辑层内部进行了更精细的职责划分。它将业务专家的语言通用语言直接映射到代码模型中确保软件核心复杂度的隔离与化解。4.3 依赖注入与控制反转实现松耦合的关键技术SoC原则要求模块间松散耦合。依赖注入是实现这一目标的核心技术。它通过将依赖关系从类内部创建转移到外部注入使得高层模块不依赖于低层模块的具体实现而依赖于抽象。Spring框架的Autowired或构造函数注入就是典型的例子。这带来了巨大的好处易于测试可以轻松注入Mock对象配置灵活通过配置切换实现类代码更清晰依赖关系一目了然。4.4 单一职责原则SoC在类级别的体现SOLID原则中的“S”——单一职责原则可以看作是SoC原则在类设计层面的具体指导。它规定一个类应该有且仅有一个引起它变化的原因。我们的重构正是遵循了这一原则JdbcUserRepository变化的原因只能是“数据库访问用户数据的方式变了”OrderService变化的原因只能是“处理订单的业务流程变了”。注意事项在实践中要警惕“过度分离”。如果一个类只被一个地方调用且逻辑非常简单强行拆分反而会增加文件数量和理解成本。分离的粒度需要权衡一个实用的判断标准是当某个逻辑单元可以独立变化、独立测试或独立复用时它就值得被分离出来。5. 进阶挑战与解决方案实录5.1 事务管理跨越多个Repository的操作一致性在我们重构的OrderService.processOrder()方法中有一个严重问题扣减多个商品库存和保存订单是两个独立的数据库操作。如果在保存订单后、扣减某个商品库存前系统崩溃就会导致数据不一致订单状态为已支付但库存没扣。这就是分布式事务问题在单数据库中的体现。解决方案使用声明式事务管理。在Spring中我们可以轻松地使用Transactional注解来保证一个业务方法内的所有数据库操作在一个事务中。Service // Spring的Service组件注解 public class OrderService { // ... 依赖注入 Transactional(rollbackFor Exception.class) // 添加事务注解 public String processOrder(String userId, ListString productIds) throws BusinessException { // ... 业务逻辑 // 现在无论是扣减库存失败还是保存订单失败整个操作都会回滚 for (Product product : products) { product.reduceStock(1); productRepository.save(product); } orderRepository.save(order); // ... } }Transactional注解会自动开启一个数据库事务方法执行成功则提交抛出异常则回滚。这确保了“扣库存”和“保存订单”的原子性。这是SoC原则的又一体现事务管理这个横切关注点被从业务逻辑中分离出来通过AOP面向切面编程技术动态织入业务代码对此无感知保持纯净。5.2 异常处理策略统一的错误应答机制在最初的混沌代码中错误处理是散落的System.out.println和return。在分层架构中我们需要一个清晰的异常处理策略。定义异常层次// 根业务异常 public class BusinessException extends RuntimeException { public BusinessException(String message) { super(message); } } // 更具体的异常 public class InsufficientStockException extends BusinessException { ... } public class UserNotFoundException extends BusinessException { ... } public class PaymentFailedException extends BusinessException { ... }在Service层抛出业务异常if (product.getStock() 0) { throw new InsufficientStockException(商品库存不足: product.getName()); }在表现层进行统一异常处理Spring提供ControllerAdviceControllerAdvice public class GlobalExceptionHandler { ExceptionHandler(BusinessException.class) public ResponseEntityErrorResponse handleBusinessException(BusinessException e) { // 返回400 Bad Request附带业务错误信息 return ResponseEntity.badRequest().body(new ErrorResponse(e.getMessage())); } ExceptionHandler(Exception.class) public ResponseEntityErrorResponse handleSystemException(Exception e) { // 记录系统异常日志 logger.error(系统内部错误, e); // 返回500 Internal Server Error对外隐藏细节 return ResponseEntity.status(500).body(new ErrorResponse(系统繁忙请稍后再试)); } }这样异常处理的关注点也被分离了。Service只负责抛出语义明确的异常ControllerAdvice负责将其转化为对用户友好的HTTP响应。5.3 测试策略针对不同层的独立测试SoC带来的最大好处之一就是可测试性。我们可以对各层进行独立、快速的测试。Repository层测试使用内存数据库如H2或测试容器专注于测试SQL是否正确、映射是否准确。Service层单元测试使用Mock框架如Mockito模拟所有Repository和外部服务依赖专注于测试业务逻辑流程和规则。Test public void testProcessOrder_Success() { // 1. 准备Mock数据和行为 User mockUser new User(user123, 张三); Product mockProduct new Product(prod1, 手机, 2999.0, 10); when(userRepository.findById(user123)).thenReturn(mockUser); when(productRepository.findById(prod1)).thenReturn(mockProduct); when(paymentService.charge(any(), anyDouble())).thenReturn(true); // 模拟保存操作实际什么也不做或验证参数 doNothing().when(orderRepository).save(any(Order.class)); // 2. 执行测试方法 String orderId orderService.processOrder(user123, Arrays.asList(prod1)); // 3. 验证 assertNotNull(orderId); // 验证库存被扣减通过Mockito验证方法调用 verify(productRepository).save(argThat(product - product.getStock() 9)); verify(notificationService).sendOrderConfirmation(eq(mockUser), any(Order.class)); }Controller层测试使用Spring的MockMvc模拟HTTP请求验证请求映射、参数绑定和响应格式是否正确。这种分层的测试策略使得测试用例更聚焦、运行更快、更容易编写和维护。6. 常见“坑点”与最佳实践心得在多年应用SoC原则的实践中我踩过不少坑也总结了一些心得。坑点1循环依赖当A服务依赖B服务B服务又依赖A服务时就产生了循环依赖。这通常是设计有问题的信号表明职责划分不清。解决方案提取公共逻辑到第三个服务C中或者使用事件驱动架构让A完成工作后发布一个事件由B来监听处理从而解耦直接的调用关系。坑点2过度抽象与“接口爆炸”为了分离而分离为每个简单的DAO都创建一个接口导致项目里充斥着只有单一实现的接口增加了不必要的复杂度。经验法则除非你明确预见到会有多种实现如不同的数据库、不同的缓存策略或者为了单元测试需要Mock否则可以推迟创建接口。YAGNIYou Ain‘t Gonna Need It原则在这里很适用。坑点3贫血模型与事务脚本虽然我们分离了层次但有时会把所有业务逻辑都塞进Service导致领域对象成了只有getter/setter的“贫血模型”Service则变成了操作数据库的“事务脚本”。这并没有真正实现业务逻辑的关注点分离。应对策略识别那些只属于某个实体自身核心行为的逻辑将其内聚到该领域模型中。例如Order.calculateTotal()、Product.reduceStock()。坑点4层与层之间的数据传递对象混乱Controller接收的CreateOrderRequest、Service之间传递的OrderDTO、Repository返回的OrderEntity如果设计不当会导致大量重复的、仅字段略有不同的类。最佳实践入参为每个API定义独立的请求类如CreateOrderRequest用于数据校验和格式转换。内部传递在Service层内部尽量使用领域模型如Order进行传递和计算保持业务语义的完整性。出参为API响应定义独立的响应类如OrderResponse或OrderDTO只暴露前端需要的字段并可以包含额外的展示逻辑。可以使用MapStruct等工具简化对象之间的转换。心得从“分层”思维到“限界上下文”思维对于大型系统单纯的三层架构可能不够。借鉴DDD的限界上下文思想可以按业务领域垂直切割系统每个限界上下文内部有自己的分层架构可能简化上下文之间通过明确的接口如RPC、消息队列进行通信。这实现了更高级别的、业务维度上的关注点分离。应用SoC原则不是一蹴而就的它是一个持续演进和重构的过程。开始时可能设计得不完美但随着对业务理解的深入不断识别出新的、独立的“关注点”并将其分离出去你的代码库就会像一座精心规划的城市分区明确、道路畅通无论是维护、扩展还是理解都会变得轻松而高效。记住好的架构不是设计出来的而是在不断应对变化和分离关注点的过程中演化出来的。