用层来组织代码库使得软件的整体结构更易观察，但这也有取舍。举个例子，为了改变特性或用户故事，你需要深入多个层（比如包、命名空间等）探究。同时，考虑到企业系统内有相当标准的分层方法，很多代码库最后看起来都惊人地相似。
鲍勃·马丁大叔在Screaming Architecture5 中说，如果你正在看一个代码库，它应该喊出跟业务领域相关的东西。以特性而不是分层来组织代码能够做到这一点，但同样有取舍。我喜欢一点细微的变化，就是明确地以组件来组织代码。举个例子，如果你去GitHub看看je.techtribes.component.tweet这个包2 ，就会发现它看起来像这样。
5 http://blog.8thlight.com/uncle-bob/2011/09/30/Screaming-Architecture.html
用组件封装
这很像以特性来封装，但它更类似于马克·尼达姆在博文6 中谈到的“微服务”。je.techtribes.component7 的每个子包都安置了一个单独的组件，具有自己内部的层和配置。只要可能，其内部的作用域都在包内。每个组件都可以拿出来，放进它自己的项目或源代码仓库，分别控制版本。如果你在构建有非常明确的松耦合架构的东西，比如由松耦合组件组成的分布式消息系统，可能会对这种方法感到很熟悉。
6 http://www.markhneedham.com/blog/2012/02/20/coding-packaging-by-vertical-slice/
7 https://github.com/techtribesje/techtribesje/tree/master/techtribes-core/src/je/techtribes/component
尽管大多数人以组件为单位考虑他们的系统，然而他们构建的东西本质上还是更整体化，对此我相当有信心。过去我当然也用类似方法封装过整体化代码库的一部分，但这往往是相当专门化的。老实说，以包来组织代码并不怎么费脑子，特别是考虑到我们所掌握的重构工具。以组件来组织代码让你可以从架构到代码库明确地反映“组件”的概念。如果你的软件架构图喊出了跟业务领域相关的东西（也应如此），这也会反映在你的代码库里。