说我有一个业务应用程序模块，例如user-management（um）。
包设计有2种方法（据我所知）。
A.datasource，um-model，um-dao，um-service，um-wab
B.datasource，um-api，um-impl
我现在更喜欢B。
我考虑一些注意事项：
根据“ java应用程序体系结构：使用osgi的示例的模块化模式”，我想要细粒度而不是粗粒度的模块。
但是，方法A的粒度太细。道应该是私人的。如果另一个模块房间预订将查询用户，则应依赖于模块（捆绑）um-api。
很少有人会设计模块（捆绑）um-dao-api，um-dao-jpa-impl，um-dao-jdbc-impl，um-dao-jdo-impl。也许um-api，um-ldap-impl，um-avos-delegate-impl是更好的设计。
数据源是一个模块（捆绑），因为我希望在应用程序模块之间进行事务处理。
所以，我认为道不应捆绑在一起。
任何想法？
谢谢！
最佳答案
尽管这里总是有一些问题，但我的经验是，以下可能是一个很好的起点：
通过将接口定义（API）放在不同的包中，将它们与实现分开。一个捆绑包仅包含具有接口的程序包（也许还有一些非常基本的POJO），将实现放在一个或多个其他捆绑包中的不同程序包中。原因：由于实现经常更改，因此依赖关系往往会随着时间的推移变得更加复杂。将API软件包放在单独的捆绑软件中可能会阻止额外的维护工作。
在接口包和包之间的包中创建清晰，清晰的分层体系结构。原因：如果未明确定义功能与程序包之间的分离，则在维护期间可能会变得更加混乱。
如果您怀疑某些功能是仅供您的实现捆绑包专用还是将来由其他功能使用，则可能会终止于其他功能。但是，您始终可以决定在实现捆绑包中定义私有接口程序包，以后可以轻松将其移植到API捆绑程序中。没有什么可以阻止您在实现捆绑包中使用模块化体系结构的，尽管有些人认为这是不必要的，因为这部分对于外界几乎是不可见的（我不同意）。
在您的情况下：如果您不希望其他功能使用DAO东西，则制作接口包并将其与实现一起放在实现包中，但不要导出该包。如果以后需要以某种方式导出它，请将接口包移至API捆绑包。
关于java - OSGi:我应该带道包吗？，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/21024282/