Question

我们目前正在审核如何将我们的核心业务组件（在代码中）与前端开发隔离开来。我们已经有了多层架构，但它们是使用dll（或某些地方的webservices）引用的。

我们想要做的是将UI的某些部分外包给外部开发人员。问题是我们必须提供可以进行逆向工程的dll，然后可以“获得”核心业务逻辑代码。

解决此问题的一种方法是使用Web服务来暴露BO，而不是使用dll公开BO。然而，几乎没有问题。例如安全性，调试，异常处理，托管等对我而言，这听起来不适合上述问题，但Web服务也不适用于此类问题。

我想知道是否有人遇到过类似情况？或者如果有人这样做了？如果是这样的话？

谢谢，

Answer 1

提供实现业务逻辑的Web服务点 - 这将由您自己托管并可供UI开发人员访问。

通过这种方式，您可以控制业务逻辑，并且UI团队可以访问API。

如果无法做到这一点，请将业务逻辑的公共接口提取到自己的软件包中，并实现一组“预制”响应 - 只需要UI用户的硬编码数据。这允许您为UI团队提供他们将要集成的界面以及示例数据，但是没有您的实际业务逻辑。

Answer 2

接口合同的概念似乎在这里发现。

如果你的接口的合同定义得很好（让它们成为DLL入口点，WSDL，无论如何），创建一个允许UI开发人员测试行为的模拟实现应该不是很困难。

我们采取的唯一预防措施是让UI承包商将代码提交到我们的SVN存储库（不，没有Git :) :)这样我们的构建机器可以连续运行集成测试，我们可以每天评估进度和问题

Answer 3

y原则可以帮助您分离您所要求的关注点。

这是一种系统地分离业务和技术问题的方法。

以下字符图形描述了该方法：

  Business requirements      Technical requirements
+------   |                             |  ------+
|         v                             v        |
|  Business model               Technical model  |
\          \                            /      /
 \          \                        /       /
   \          \                    /       /
     \          > Mapping rules <        /
       \              |                /
         \            |              /
          \           v             /
           \    Implementation     /
            \         |           /
             \        |          /
              \       v         /
               Acceptance Tests

如果映射规则一致且可以重复应用，则可以自动化该方法。反向分析可以显示是否是这种情况。

如果该方法适用，将对效率产生深远影响。而不是必须一遍又一遍地将业务问题映射到技术问题该过程可以重复并最终实现自动化。

您可以在我的公司网页上找到更多相关信息。

架构隔离机制

3 个答案: