在设计企业API时，哪个级别适合分离库？
假设我们正在为企业公司开发REST系统，以便在基于Java的应用程序中公开公司资源。最终，您有一个web应用程序和域库。我的问题是组件和服务应该在这些域库中的位置，以及应用程序本身应该存在什么。
对于一个假设的公司，我们可能有几个领域。
- 客户关系
- 客户销售订单
- 制造业
- 产品结构
- 供应链
- 仓储
考虑到这些域，我们将拥有用于持久化的域对象和对象服务。然后，我们可以将它们进一步划分为实现。
- 客户关系
- 客户关系- JDBC
- 客户销售订单
- 客户销售订单- JDBC
- 制造业
- 制造- JDBC
- 产品结构
- 产品结构- JDBC Impl
- 供应链
- 供应链- JDBC
- 仓储
- 仓储- JDBC
现在，它开始看起来很复杂，这仅仅是因为我们管理了多少个单独的库。我想知道，我们是否需要分离到这样的水平，并可以简单地拥有这三个。
- 业务接口
- 业务JDBC
- REST应用
我问题的第二部分涉及到服务类和管理类应该住在哪里。考虑到上面的仓库，我们需要域对象来表示拾取面，需要一个DAO类来管理挑面对象，最后需要一个rest应用程序的服务组件。为此，我们可以看到以下结构。
- 仓储
- PickFace
- PickFaceDAO
- 仓储- JDBC
- JdbcPickFaceDAO
- ReST应用程序
- PickFaceController
一方面，PickFaceController在ReST应用程序中是最好的，因为应用程序随后可以手动管理该控制器的服务，并且可能需要自定义配置。
但是，另一方面，PickFaceController在仓库项目中可能更好，因为它只关注仓库模块，但是ReST应用程序理论上可以使用服务定位器在其他库中查找服务。
那么，正在使用的成功方法是什么呢？你什么时候知道什么时候你已经走得很远了，分开或做得不够？你怎么知道放东西的最好地方？
回答 1
Software Engineering用户
发布于 2012-08-24 10:45:09
您应该看看-当使用域驱动设计时，它工作得非常好。
总之，洋葱架构倡导将你的应用程序划分为依赖最少/寿命最长的应用程序，使之成为最依赖/最短的生命。具有存储库接口的域类将保留在核心中，而特定的实现将驻留在外层。
通常，您会有这样的东西(top没有依赖项，下面所有的内容都取决于上面的内容)：
- 共同/共享核心功能
- 核心层-域模型，域服务，接口
- 应用层-编制和反腐败层
- 基础结构层--通常是域接口的具体实现
- 表示层
这里的想法是，公共/共享核心功能随处可见(主要是帮助者，不应该包含域逻辑本身)。
应用程序和基础设施层将取决于核心层和公共/共享核心功能。
表示层将依赖于应用程序、基础设施和公共/共享核心层，而不是直接位于核心层的顶层，以确保防腐败。
可能有多个应用程序层--这取决于您可能拥有多少个端点(一个应用程序层可能是一个Web服务)。您不希望表示层直接依赖于核心域模型，因为它使单一责任原则(域逻辑应该应用于域模型--鉴于域对象，数据传输对象的责任对域逻辑的实现施加了某些限制)。
我希望这个指导对你有价值。我不能准确地判断应该如何将项目分成不同的库，因为这将取决于其他因素。
最后，没有什么能阻止您将所有这些都放在一个程序集中。您通常会根据有界的上下文(自包含的)将它们分开，以确保在逻辑分离级别上进行依赖反转。还有一些实用工具可以将多个库合并成一个用于部署的库。
https://softwareengineering.stackexchange.com/questions/162110
复制相似问题
腾讯云开发者
