Сервисный дизайн (WCF, ASMX, SOA)

Question

Запрос отзывов / мыслей о шаблоне или передовой практике для решения ситуации, с которой я сталкивался несколько раз за эти годы, но я не нашел ни одного решения, которое бы решало его так, как мне бы хотелось.

Вот фон.

Компания имеет 3 приложения, поддерживающие 3 отдельных «направления деятельности», которые очень тесно связаны друг с другом. Два приложения буквально копируют / вставляют из оригинала. Приложения должны иметь возможность расти с разной скоростью и иметь несколько разные функциональные возможности. Основные различия в функциональности связаны с полями ввода данных. Различия по сути делятся на одну из следующих категорий:

1. Один экземпляр имеет несколько полей что другой не делает.
2. Строковое поле имеет максимальную длину 200 в одном экземпляр, но 50 в другой.
3. Поля поиска / ссылки имеют разные базовые значения (т.е. те же структуры таблиц, но ближайшие из разных баз данных).
4. Поле определяется как предоставленное пользователем, свободный текст, значение в одном экземпляре, но поиск / ссылка в другом.

Проблема заключается в том, что в компании существуют другие приложения, которым необходимо использовать данные из этих трех отдельных приложений, но в идеале они должны взаимодействовать с ними централизованно / централизованно (т.е. через центральную службу, а не через 3 отдельные службы). Мой вопрос заключается в том, как обращаться, в частности, с пунктом D выше. Я думаю, что подход «наименьшего общего знаменателя» может быть единственным способом. Например:

<SomeFieldName>
  <Code></Code> <!-- would store a FK ref value if instance used lookup, otherwise would be empty or nonexistent-->
  <Text></Text> <!-- would store the text from the lookup if instance used lookup, would store user supplied text if not-->
</SomeFieldName>

Другие мысли / идеи по этому поводу?

ТИА!

Answer 1

Таким образом, различия строго соответствуют представлению Datamodel или существуют функциональные различия между бизнесом и поведением на уровне приложения.

Если последним является случай, то я определенно пошел бы по пути, который вы, похоже, направляете с SOA. То, как вы реализуете свою SOA, зависит только от потребностей вашей архитектуры. То, на что я смотрю для дизайна, будет в несколько различных шаблонов. Трудно сказать наверняка, какие из них удовлетворят потребности без дополнительной информации / примера того, как используются поведенческие / функциональные различия. От вершины моей головы до того, что вы описали, я, вероятно, начну с рассмотрения шаблона Стратегии в моем первоначальном проекте.

Определите прототип этого, используя TDD, чтобы вы могли определить, движетесь ли вы по правильному пути.

Answer 2

Как насчет: расширить ваш ЖК-подход, поставить фасад перед этими системами. разработать нормализованную форму данных, которая (при заполнении достаточным количеством данных) может быть преобразована в любой из конкретных экземпляров. [Направляясь к ESB здесь.]

Тогда у вас проблема, как клиент узнает, что такое «достаточно»? Могут потребоваться какие-то метаданные, чтобы вы могли представить подходящий пользовательский интерфейс. Поэтому расширьте сервисы, чтобы обеспечить операцию по доставке метаданных.