将特定于应用程序的项(如API、数据库模型(和特定于平台的项分开是个好主意吗？例如：我有一个酒店管理平台(如预订、客房等(，服务以API的形式公开，它有自己的数据模型。
如果我喜欢使用该平台来实现像资产管理这样的用例，比如(床、桌子、存货及其生命周期等的数量(
将新的数据模型单独包含在现有的特定于平台的模型中是个好主意吗？或者我可以创建一个新的应用程序后端，并将新的数据模型和特定于用例的API分离出来吗？
使用松散耦合的体系结构(保留单独的应用程序特定项和平台特定项(总是很好的。原因是，一旦你通过了超小型项目，每次更改或更新都会变得越难，耦合越紧密。松散耦合使你能够继续前进，添加功能，修复错误等。
根据我开发大规模应用程序的经验，在某一点上，我认为任何程序都会成为维护、更新和添加的噩梦。设计越松散，这一点就越延迟。如果它是紧密耦合的，也许在大约10000行代码之后，它就变得不可维护了，如果不从头开始重写，添加一些功能就变得不可能了。
松散耦合允许它增长到1000000到10000000行代码，同时仍然能够在合理的时间内进行更改和添加新功能。这些数字并不是字面意义上的，因为它们只是虚构的，而是为了让人知道它在哪里变得有用。对于您这种应用程序，我更希望您为后端创建一个新的应用程序，并将新的数据模型和特定于用例的API分开。
它越是松散耦合，应用程序的寿命就越长
关注点的分离和实用性之间应该始终保持平衡。在一个非常简单的项目中，过于松散地耦合可能会过度使用，并产生不必要的复杂性。所以答案是：这取决于当前和未来的需求。
在您的情况下，如果您只使用该平台，那么直接集成它就可以了，而无需引入新的"中间"数据模型或服务。然而，如果您计划将新的业务逻辑添加到平台的功能中，即将其用于需求的某些部分，为其他部分实现修复、更改或新功能，那么引入新的独立服务可能会有所帮助。一个直接的优势是可以选择实现单元测试，特别是针对您的实现。