核心公司数据在物理上独立的第三方业务线应用程序中进行管理和管理：财务，运输管理。客户在财务应用程序（SQL Server）中创建，交付信息保存在传输管理应用程序（Oracle）中。两者之间的沟通是点对点的。
我们需要建立一个新的应用程序（很好地升级旧的应用程序，但基本上是从头开始）来处理客户对损坏或短交付的索赔。索赔，客户和交付数据目前手动输入MS Access。这将迁移到SQL Server DB。应用程序开发平台是VS2008（C＃）。
我想避免在声明数据库中包含所有客户和交付数据，因为我们已将其保留在其他位置，因此我计划从LOB系统（可能还有声明数据库）生成基于WCF的订阅源，然后可以用作客户索赔应用程序的数据源。将有特定于声明的数据输入，但核心客户和交付数据不需要在LOB应用程序中更新。
到目前为止，我想到了
数据库 - ＆gt; ORM - ＆gt; WCF \
数据库 - ＆gt; ORM - ＆gt; WCF ---＆gt; BLL - ＆gt; UI
数据库 - ＆gt; ORM - ＆gt; WCF /
但感觉不对，因为我将为客户，交付和索赔（面向对象的服务？）创建单独的服务提要。我还无法理解的是，我在应用程序中加入和处理数据源的方式和位置，例如，生成一个报告，显示每个客户的交付索赔（即我传统上写一个查询或视图来获取所有这来自一个数据库中的多个表。）
我是在正确的轨道上还是我错过了这里的大局 - 我是否应该定期提取索引数据库并使用传统的n层/ n层架构？
答案 0 :(得分：4)
我认为你的设计离它应该的位置太远了。
如果您的应用程序可以通过WCF服务或传输服务访问财务数据，那么构建它们是有意义的。它们也有意义构建，因为每个服务都支持它需要知道的内容（与单一责任原则相关联）。
可能感觉不对的是UI应用程序需要了解的位置，并调用3个单独的服务来完成其工作。在这种情况下，我们经常构建一个包装服务来调用适当的服务。这意味着您的UI应用程序将引用WCF服务，然后该服务将调用Finance服务或传输服务或声明服务。下行 - 每次通话都会导致多次通话......是的。但它将逻辑从您的UI应用程序中抽象出来，并提供了一个好处，让您可以操作或组合来自其他服务的数据，或添加适合该应用程序的其他业务逻辑。您还可以享受财务服务仍然支持财务应用程序的好处，而不会影响您的UI应用程序的业务需求，或者为了它的利益而混淆代码。
我确信这有不同的解决方案路径。这就是我们在几个应用程序中处理的方式。
编辑（回答您的跟进问题需要太多空间才能发表评论）。
如果您可以从传输服务获得的数据足以满足通过说“getCustomerDelieveries”提出的问题，那么我不会将其分解为另一个包装器服务。如果您需要更多数据，那么其他应用程序也会从提供更多客户信息的服务中受益？这些应用程序是否依赖运输服务？这是答案必须“感觉”适合您的一个，因为您对系统了解最多。
也许您需要中断SRP规则并让您的传输服务从财务数据库或服务获取更多客户信息。或者，如果依赖于传输服务的应用程序通常需要更多客户数据，则可以考虑扩展传输数据库中的客户表。
任何规则，原则或哲学都不应该如此严格地应用，如果它对你的应用更有意义，你就无法打破它。这将是一个平衡，没有正确或错误的答案，只有在这种情况下更有效。
您通过讨论支持业务声明部分的新UI应用程序开始这篇文章，它需要财务和传输数据（以及它自己的数据）。这是调用包装器服务的完美候选者。它需要来自3个不同且独立数据源的数据。您的传输服务有限的客户信息适用于某些应用程序，但对其他应用程序可能不太好。如果您编写的包装服务能够100％反映您的传输服务并另外提供更多的客户数据，您获得了什么？为使用它的应用程序提供更多数据，但每当您向传输服务添加功能时，都会为您提供更多维护。这个包装器还能提供什么其他价值？
在这种情况下，对我来说，让Transport服务从Finance服务获得更多客户数据“感觉”更好。您的传输数据库有一些数据，但还不够。这几乎就像运输服务需要通过填补数据需求来弥补这一短缺。
答案 1 :(得分：0)
生成报告时，通常可以容忍提供最新的数据，因此将单独的数据库用作报告查询的来源可能是个好主意。您的主数据库将从UI接收更新（利用事务和冲突检测），然后将数据复制到报告数据库。
这种架构模式称为CQS（命令查询分离），由Udi Dahan读取此great article。
答案 2 :(得分：0)
我应该使用WWF（或其他业务流程工具）的业务流程服务。
我喜欢这个观点：
DAL，BLL，SIL - ＆gt; WCF1 DAL，BLL，SIL - ＆gt; WCF2
wcf1和wcf2由业务流程服务加入。这样，服务保持自治和解耦，您可以在其他业务流程中重用它们。