Дизайн сервиса (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> 

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

TIA!

Answer 1

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

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

Определите этот прототип с помощью TDD, чтобы вы могли определить, идет ли ваш курс по правильному пути.

Answer 2

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

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