仔细想了下模块划分，其实也不简单-量化

手艺人王学明

于 2021-04-02 17:22:44 发布

阅读量451

点赞数

CC 4.0 BY-SA版权

分类专栏： [工作记录] [架构及模式] 组件化文章标签：模块划分规范模块划分模块划分规范

本文链接：https://blog.youkuaiyun.com/wangxueming/article/details/115123110

本文探讨了衡量模块划分的标准——沟通量，强调了职责划分和代码边界的重要性。通过功能划分，借助仓库和接口定义来管理数据依赖。文章提出了三个指标：参数必要性与合理性、接口变动频率和接口重合度，以评估接口设计的合理性，并强调了业务逻辑的适配性和团队规模对粒度的影响。最后，作者提倡通过日常反思和持续调整来优化模块划分。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在这里插入图片描述
我们今天聊一聊研发的依赖问题。

一个App就是一堆git仓库+一堆逻辑的组合，就构成了完整的业务逻辑。

衡量模块划分的标准其实就是 “沟通量”。

换个词语：职责划分、代码边界。

常用的划分是功能划分

通过引入各种仓库，给我们的研发带来了边界

api 'jp.wasabeef:glide-transformations:4.0.1'
api "com.github.bumptech.glide:glide:${glide_version}"
//黄油刀
annotationProcessor "com.jakewharton:butterknife-compiler:$rootProject.butterknifeVersion"
api "com.jakewharton:butterknife:$rootProject.butterknifeVersion"

第三方库会明确的程序提供了什么功能，有个主入口。尽量将逻辑都包裹在内部。其主要的设计理念：职责明确出来。
通过编写一堆的interface来定义代码的能力。

这也引出了我们沟通的第一个问题：数据依赖
为了规矩数据依赖，接口定义需要充分考量。
如何定义接口定义是否合理？入参有哪些？

核心