即使只是少量更改角度，也可能对您如何使用系统产生深远影响。

假设您正在用Java编写Web应用程序。 在系统中，您处理订单，客户和产品。 作为Web应用程序，您的类包括诸如Controller，PersonRepository，CustomerController和OrderService之类的订书钉。 您如何将课程组织成包？

有两种基本的方法来构建软件包。 您可以专注于逻辑层，例如com.brodwall.myapp.controllers，com.brodwall.myapp.domain或com.brodwall.myapp.services.customer。 或者，您可以专注于域上下文，例如com.brodwall.myapp.customer，com.brodwall.myapp.orders和com.brodwall.myapp.products。 迄今为止，第一种方法最为普遍。 在我看来，它也是最没有帮助的。

如果您围绕领域概念而不是技术层来构建软件包，则可以通过以下几种方式改变思维：

首先，也是最根本的，您的思维模型现在将与系统用户的思维模型保持一致。 如果要求您实现典型功能，那么现在很可能将重点放在系统软件包的严格子集中。 例如，向表单添加新字段将至少影响相应域概念的表示逻辑，实体和持久层。 如果您的软件包是围绕层组织的，则此更改将影响整个系统。 一句话：围绕功能而非技术组织的系统具有更高的一致性。 这个技术术语意味着一个类的大部分依赖项都位于该类附近。

其次，随着软件的发展，围绕领域概念进行组织将为您提供更多选择。 当一个程序包包含数十个类时，您可能需要将其拆分为几个程序包。 讨论本身可以启发人。 “也许我们应该将客户地址类别分离到com.brodwall.myapp.customer.address包中。 它似乎有自己的生活。” “是的，也许我们可以在需要地址的其他地方使用相同的类，例如供应商？” “很酷，那么com.brodwall.myapp.address呢？” 或者，也许您认为应该将订单状态代码和付款状态代码放在“ com.brodwall.myapp.order.codes”包中。

另一方面，您有什么选择拆分com.brodwall.myapp.controllers？ 您可以为客户，订单和产品创建子包，但是这些子包可能只具有一个或两个类。

最后，也许是最有趣的是，使用领域概念进行包装可以使您根据具体情况改变设计。 也许您确实需要一个OrderService来协调订单的付款和运输，而ProductController仅需要带有存储库的基本create-retrieve-update-delete功能。 一个ProductService只会给您带来麻烦。 如果com.brodwall.myapp.services包中缺少ProductService，这可能会造成混淆，或者至少会给您带来麻烦的感觉，那就是出现了问题。 另一方面，如果com.brodwall.myapp.product程序包中没有控制器，则没关系。

而且，大多数系统都有一些不错的零件，而有些则不太好。 如果您的服务包对您不起作用，那么您将无能为力。 但是，如果“产品”程序包烂了，您可以将其丢弃并重新实现它，而不会使整个系统陷入混乱状态。

通过将实现某个功能所需的类彼此放在一起，并与实现其他功能所需的类分开，开发人员在开发一个功能时可以务实和创新，而不会负面影响其他功能。

不利的一面是，大多数开发人员对应用程序中的某些技术更满意，而对其他技术则较不满意。 围绕功能而非技术进行组织会迫使每个开发人员考虑更多的技术挑战。 有些程序员将其视为学习的动力，而其他程序员似乎宁愿不必学习新知识。

如果花我的钱来创建功能，我就知道我想要什么样的开发人员。

细微的变化会产生很大的影响。 通过围绕功能组织软件，您将获得一个更加一致的系统，可以进行扩展。 它可能会给您的开发人员带来挑战，但会降低实现功能所需的交接数量，并会挑战开发人员以改善他们正在处理的应用程序部分。

参考： Java 合伙人 Johannes Brodwall在“ 更大的盒子里的思考”博客中的更改Java包名称如何改变了我的系统架构 。