Java应用程序结构：水平拆分与垂直拆分

对于大型Java应用程序的启动项目结构（使用Maven / Eclipse）有一些争论。

选项1：

entities (i.e. the whole database using Hibernate classes-first)
services (i.e. sets of read/write operations on the entities)
app (perhaps split up more further down the line)

选项2：

area1-entities
area1-services
area1-app
area2-entities
area2-services
area2-app
...
(where area1, area2 etc. are functional areas of the system)

选项2显然将导致产生更多的Maven项目/模块，这意味着将生成数据库的类分布在多个项目中。谁能建议每种方法的利弊？

我建议都不做。

尝试通过包结构强制进行技术分层会导致应用程序发生大量纠缠。更不用说我们如此努力地将所有内容隐藏在服务接口后面的事实，而我们要做的第一件事（主要是由于包装）使一切成为a public class。当x.y.z.service和x.y.z.repository软件包之间存在技术分离时，这变得很痛苦，现在所有内容都可以访问存储库。繁荣将您封装在服务层内。

相反，您应该遵循一种更加实用且基于洋葱的方法（干净的体系结构，六边形体系结构）。这也很好地符合“ 单一责任原则”（适用于包装时），也符合包装原则

1. 一起变化的事物被打包在一起
2. 一起使用的东西被包装在一起

Oliver Gierke 在Java上将组件打包在一起写了一篇不错的文章。西蒙·布朗（Simon Brown）撰写了关于该主题的更一般的故事。

我将努力争取如下所示的核心软件包结构，以保持您应用程序的核心：

x.y.z.area1
x.y.z.area2

现在，如果您具有Web界面，则可以添加一个web子包（例如，用于webservice a ws或rest包的子包）以仅容纳该子包。它基本上连接到核心。

x.y.z.area1.web
x.y.z.area1.ws
x.y.z.area2.rest

现在您可以考虑将对象从内核内部重用到其他层，但是恕我直言，最好在该层使用特定的域。同样，就像对象到SQL的映射一样，（通常）我们希望在屏幕上显示的内容或在Web服务中用作XML的内容以及业务逻辑的实现方式不匹配。根据业务和Web域的复杂程度，您可以将它们视为单独的问题域，以解决需要连接的问题域，基本上是2种不同的有界上下文。

使用CQRS资源中的报价

不可能使用单一模型来创建用于搜索，报告和处理交易的最佳解决方案。

不要尝试将所有内容放入单个（域）模型中，将职责分开。您可能最终得到了更多（较小）的类，但应用程序各层之间的分隔更加清晰。

最后说明

记住，创建架构是在权衡一种解决方案与另一种解决方案之间的权衡。它在很大程度上取决于域的复杂性，并且主要应由应用程序的功能要求来驱动。但是，它受非功能性（性能，安全性）和环境限制（使用语言，平台，经验）的影响。而且，像编码这样的体系结构永远不会完成，每个新的需求都可以（也许应该？）导致应用程序的重新设计。

免责声明

是的，我还尝试将所有内容放在一个模型中，是的，我还尝试在应用程序中使用技术上的分隔。但是，在创建纠缠的应用程序分层有几年经验之后（最初似乎是个好主意，然后应用程序开始增长...），我认为必须有另一种方法。

链接

1. 清洁建筑，鲍勃·马丁叔叔
2. 六角建筑（又名端口和适配器），Alistair Cockburn
3. 哎呀，我的建筑去了哪里，奥利弗·吉尔克（Oliver Gierke）
4. OOD原理，鲍勃·马丁叔叔
5. 应用DDD时的错误，Udi Dahan
6. 有限的上下文，马丁·福勒（Martin Fowler）
7. 建筑上明显的编码风格，Simon Brown

图书

1. 不断增长的面向对象软件，以测试为指导
2. Java应用程序体系结构：使用OSGi的示例的模块化模式（Robert C. Martin系列）
3. 域驱动设计：解决软件核心问题的复杂性
4. 开发人员的软件架构
5. 实施域驱动设计