Java 程序设计-按功能和/或层进行包装？

我正处于web应用程序的设计阶段，该应用程序允许用户创建工作请求，并允许工作人员根据这些请求投入时间。该应用程序还将为主管提供报告功能，以获取每日总计、报告，并说明所花费的时间，“成本分配”

我在过去工作过的应用程序都是使用逐层包的方法设计的。我认为通过功能设计使用软件包会更有效，我对这种设计有一个问题

我目前对各功能包的想法：

请求-CRUD请求，然后分配，添加发票号等

工作时间-针对请求、假期、培训或会议，用户每天的CRUD时间

成本分配-创建报告，会计的东西，会计想要

前端将是Tomcat服务器和JSP。而且，后端将是一个Oracle数据库，EclipseLink将执行持久化

我的问题:

---

在我对package by feature的理解中，实体和DAO将进入与其关联的包中。将持久性层分散到多个包中。让包从其他包调用实体。有这么多的重叠，这真的有用吗？包之间不会有隔离。按功能使用软件包的优缺点是什么？使用额外的持久性层是一种好的设计吗？或者，我对这一点的理解完全错误吗？

我建议开始基于业务实体进行打包。在那里你可以根据层次来划分事物

所有的重叠是真的吗 功能性的

我练习了很长时间。我认为这种方法没有任何重大问题。您必须找出要解耦的内容以及应该解耦多少。例如，使用

orders

提供的API从

customer

包调用

orders

的持久方法对我来说非常好

使用的优缺点是什么 按功能打包

我发现它比严格的面向层的包装更简单、更直接、更容易理解和使用。当您想要将内容拆分并分发到不同的地方时，它会带来好处

搭配一个新的设计好吗 额外的持久层

看看这条线

进一步阅读

---

如果我愿意在两个功能包和一个层包之间进行选择。我会选择分层包装

出于几个原因

• 在分层arhcitecture中，应在层之间明确定义接口/依赖关系，适当的打包将很快突出显示是否存在不需要的依赖关系
• 它将一个层（例如使用Oracle的持久性）中的依赖项与其他层隔离开来
• 我发现把每一层都孤立起来考虑会更干净

但要回答您的问题，功能与层或两者兼而有之，我会说两者，主要是按层打包，然后按功能打包。

5年后

（背景中的悬疑音乐）

想象一下这种荒谬的情况：

经理公司、程序员公司、人力资源公司和营销公司，其中程序员公司只有程序员，没有经理、营销人员或人力资源

我们不想按职业划分同事，而不是组织（自我协调）团队，或者我们会这样做吗

把东西按原样包装在一起，而不是按它的功能包装，只会让你跳10次到你要找的地方

---

那不是看起来很性感吗？通过查看结构，您已经可以了解应用程序的全部内容。不满意

那么在所有功能中使用的实体呢？示例：请求是请求包中的CRUD。然后，它们用于将时间与工作时间进行对比，并在成本分配中进行报告。我假设它们将与Requests包中的所有查找表一起定义一次，并用作其他包中的对象。那么，在其他包使用的请求包中，查找代码是否会被使用呢？对于跨层使用的实体，我会考虑使用一个“框架”包，它不提供自身的特性，而是允许跨层重用共同代码。在这种情况下，将是请求、工作时间对象加上查找表实体？还是我没抓住重点？@Miller-我不明白。你的论点虽然有效，但似乎完全反对按功能包装，而不是按层包装（这是哈菲兹所提倡的）。我理解你的意思。我曾想过要去掉DAO层，但在如何做到这一点上遇到了问题。在Eric Evans的书DDD中，他谈到了使用存储库模式。这是否提供了与DAO类似的功能？我仍在掌握这些概念，请原谅我的错误。另外，是否有一个好的代码示例可以更好地了解DDD？@Miller:是的，有点类似。客户机使用表达式API或声明方式创建查询，并将其传递到存储库以获得满足。您可以将JPA视为DAO层，正如我提供的线程中所建议的那样。然后实体管理器将被注入到存储库中，对吗？这将允许在该层使用JPA功能。@Miller:实体管理器将被注入到您的业务组件中，并作为业务组件的存储库工作。将JPA视为存储库模式的实现。此外，我在上面的原始答案中添加了一个链接。@AdeelAnsari您是否有一些手册和参考链接，用于演示如何基于业务实体进行打包？