架构隔离机制

Question

We are currently reviewing how to isolate our core business components (in the code) from the front end development. We already have multi-tier architecture but they are referenced using dll (or webservices in some places).

What we would like to do is to outsource some part of UI to external developers. The problem is that we have to provide the dll which can be reverse engineered and the core business logic code then can be "obtained".

One way to tackle this instead of exposing BO using dll, use Webservices to expose BO. However there are few problems. for eg Security, Debugging, exception handling, hosting etc. To me this does not sound right for the issues mentioned above but also web services are not meant for such problems.

I am wondering does anyone has come across similar scenario? or If someone has done this? if so how?

Thanks,

Answer 1

Provide a web service point that implements the business logic - this will be hosted by yourselves and accessible to the UI developers.

This way you keep control of your business logic and the UI team have access to the API.

If this is not possible, extract the public interfaces of your business logic into its own package and implement a set of "canned" responses - just hard coded data for the UI people to work with. This allows you to give the UI team the interface they will integrate with as well as sample data, but without your actual business logic.

Answer 2

The concept of interface contract seems spot-on here.

If the contracts of your interfaces are well defined (let them be DLL entry points, WSDLs, whatever), it should not be very difficult to create a mock implementation that allows the UI developers to test the behaviour.

The only precaution we took is to ask UI contractors to commit code into our SVN repository (no, no Git here :)) so that our build machine could run integration tests continuously and we could assess progresses and issues on a daily basis.

Answer 3

The y-principle might help you to get the separation of concerns you are asking for.

It is a method for separating business and technical concerns in a systematic manner.

The following character graphic depicts the approach:

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

The approach can be automated if the Mapping rules are consistent and can be repeatedly applied. A reverse-y analysis can show whether this is the case.

In case the approach is applicable it will have a profound effect on efficiency. In stead of having to do the mapping of business issues to technical issues over and over again the process can be made repeatable and eventually automated.

You can find more on this on my companies webpage.