在一个相对较大的项目中，需要考虑将功能拆分为各种功能，然后是各种模块，然后是各种包。有时跨不同的源分布（例如：将一个通用实用程序（例如 optparser）提取到一个单独的项目中）。
问题 - 如何决定将哪些部分放入同一模块中，哪些部分放入单独的模块中？包裹也有同样的问题。
【问题讨论】：
David Parnas 有一篇经典论文，名为“关于将系统分解为模块时使用的标准”。这是一部经典（并且有一定的年代，所以可能有点过时）。
也许你可以从那里开始，这里有一个 PDF 文件
http://www.cs.umd.edu/class/spring2003/cmsc838p/Design/criteria.pdf
【讨论】：
拿出一支笔和一张纸。试着画出你的软件在高层次上是如何交互的。绘制软件的不同层等。按功能和目的对项目进行分组，甚至可能按它们使用的技术类型。如果您的软件有多个抽象层，我会说按此对它们进行分组。在高层次上，特定层的元素都具有相同的通用目的。现在您已经将软件分层，您可以根据特定的功能或专业化将这些层划分为不同的项目。
至于你达到的某个阶段，你应该这样做吗？我会说当你有多个人在代码库上工作或者你想让你的项目尽可能地模块化时。希望您的代码足够模块化以执行此操作。如果您无法从高层次上拆分您的软件，那么您的软件可能是意大利面条代码，您应该考虑重构它。
希望这会给你一些工作。
【讨论】：
见How many Python classes should I put in one file?
画出你的整个类定义集。
将这些类定义划分为“模块”。
分别实现和测试模块。
将模块组合在一起以创建您的最终应用程序。
注意。分解一个有机发展的工作应用程序几乎是不可能的。所以不要那样做。
尽早并经常分解您的设计。构建单独的模块。集成以构建应用程序。
【讨论】：
恕我直言，这可能是您在开发过程早期所做的事情之一。我从来没有参与过大型项目，但是你制定一个关于将要做什么和在哪里做的路线图是有意义的。 （不要像你犯了一个错误一样试图嘲笑你问这个问题：D）
模块通常按用途或功能以某种方式分组。您可以尝试接口的每个实现，或其他连接。
【讨论】：
我很同情你。你正在遭受自我怀疑。别担心。如果你会说任何一种语言，包括你的母语，你就有资格自己做模块化。作为证据，您可以阅读“语言本能”或“数学本能”。
环顾四周，但不要太多。你可以从他们身上学到很多东西，但你也可以从他们身上学到很多不好的东西。
一些项目/框架得到了很多炒作。然而，它们的某些功能分组，甚至模块的名称都具有误导性。他们不会“揭示程序员的意图”。他们未能通过“高凝聚力”测试。
书籍再好不过了。请在您的图书选择中应用 80/20 规则。即使是像 Capers Jones 的 2010 年“软件工程最佳实践”这样经过深入研究的好书也是毫无头绪的。它说 10 人的敏捷/XP 团队将需要 12 年的时间来做 Windows Vista 或 25 年的时间来做一个 ERP 包！它说直到 2009 年才有分割方法，它是模块化的术语。我不认为它会帮助你。
我的观点是：您必须非常仔细地选择您的模型/参考/示例来源。不要高估名人而低估自己。
这是我的帮助，我的经验证明了这一点。
这很像决定哪些属性到哪个数据库表，哪些属性/方法到哪个类/对象等？在更深的层面上，这很像在家里布置家具，或者在书架上放书。你已经做过这样的事情了。软件一样，没什么大不了的！
先担心“凝聚力”。例如书籍（Leo Tolstoy、James Joyce、DE Lawrence）是有选择的。（HTML、CSS、John Keats。jQuery、tinymce）不是。并且有很多方法可以安排事情。就连分类学家也对此存在严重的争执。
然后担心“耦合”。怕羞”。 “不要和陌生人说话。”不要过于友好。尽量让你的包/数据库表/类/对象/模块/书架自包含，尽可能独立。 Joel 谈到了他对 Excel 团队的钦佩，他们厌恶所有外部依赖，甚至构建了自己的编译器。
【讨论】：
实际上，它因您创建的每个项目而异，但这里是一个示例：
core 包包含您的项目不能没有的模块。这可能包含您的应用程序的主要功能。ui 包包含处理用户界面的模块。也就是说，如果您将 UI 从控制台中分离出来。这只是一个例子。真正由您决定去哪里和去哪里。
【讨论】：