设计模式-业务系统开发(十四)

纲要

完整的系统流程包括：

  1. 前期的需求沟通分析
  2. 中期的代码设计实现
  3. 后期的系统上线维护

需求分析

做为技术人员不仅仅是等着产品设计文档，线框图，照着实现就可以。应该参与到产品设计中。具有产品思维，前期应该去市场上调研，参考，借鉴已成熟的产品。充分了解自己公司的产品后，然后再将其糅合到自己的产品中，并做适当的微创新。

  1. 调研产品
  2. 充分了解自家产品
  3. 微创新

tip: 技术人也要有一些产品思维

系统设计

  1. 合理地将功能划分到不同模块

合理地划分代码可以实现代码的高内聚，低耦合，类与类之间的交互简单清晰，代码整体结构一目了然。

  1. 设计模块与模块之间的交互关系

    • 同步接口调用
      • 适合上下层之间的关系
    • 异步接口调用
      • 适合同级间的关系

  2. 设计模块的接口，数据库，业务模型

代码实现

前提

数据库和接口设计非常重要，一旦设计好并投入使用之后，这两部门都不能轻易改动。

  1. 改动数据库表结构，需要涉及数据的迁移和适配。
  2. 改动接口，需要推动接口的使用都作相应的代码修改。

一定要多花点心思和时间，切不可过于随意。

业务逻辑代码侧重内部实现，不涉及外部依赖的接口，也不包括持久化的数据，所以对改动的容忍性更大。

MVC

  1. Controller 层负责接口暴露
  2. Repository 层负责数据读写
  3. Service 层负责核心业务逻辑

两种开发模式

  1. 充血 DDD 开发模式
  2. 贫血 OOP 开发模式

为什么使用MVC开发

  1. 分层能起到代码复用的作用
    • 同一个 Repository 可能会被多个 Service 来调用。
    • 同一个 Service 可能会被多个 Controller 调用。
  2. 分层能起到隔离变化的作用
    • Repository 层封装了对数据库访问的操作，提供了抽象的数据访问接口。
    • 基于接口而非实现编程的设计思想，Service 层使用 Repository 层提供的接口，并不关心底层依赖是哪种具体的数据库。
    • 如果需要替换不同的数据库，只需要修改 Repository 层，Service 层的代码完全不需要修改。
    • 三层的稳定程序也不同。越底层越应该稳定。
  3. 分层能起到隔离关注点的作用
    • Repository 层只关注数据的读写。
    • Service 层只关注业务逻辑，不关注数据的来源。
    • Controller 层只关注与外界打交道，数据校验，封装，格式转换，并不关心业务逻辑。
    • 三层之间的关注点不同，分层之后，职责分明，更加符合单一职责原则，代码的内聚性更好。
  4. 分层能提高代码可测试性
    • 使用依赖注入方式，采用 mock 数据替代真实数据。
  5. 分层能应对系统的复杂性
    • 水平方向基于业务来做拆分，就是模块化。
    • 垂直方向基于流程来做拆分，就是分层。

tip: 对于工作不满意，应该我花点时间在技术上;对于当前工作很满意则多花时间在业务上。

关于我

我的博客：https://yezihack.github.io

欢迎关注我的微信公众号【空树之空】，共同学习，一起进步~ 空树之空