SOA / WCF, рассекающие границы системы и сервиса

Question

Я строю систему, которая будет иметь несколько каналов, питающих разных клиентов (MonoDroid, MonoTouch, Asp.Net Mvc, REST API)

Я пытаюсь принять архитектуру SOA, а также пытаюсьпринять модель постоянства по достижимости (http://www.udidahan.com/2009/06/29/dont-create-aggregate-roots/)

. Мой вопрос относится к проектированию архетектуры. Как наилучшим образом разделить систему на отдельные фрагменты, чтобы извлечь выгоду из SOA.

В моей модели естьSystemImplementation, которая представляет собой установку самой системы, а также сущность Account.

То, как я изначально задумывался об этом, заключалось в создании служб в виде:

• SystemImplementationService -отвечает за управление вещами, связанными с самой установкой, такими как брендинг, регистрация трафика и т. д.
• AccountService - отвечает за управление активами пользователей (медиа, сеть контактов и т. д.)

Логическирегистрация новой учетной записи пользователя будет происходить в AccountService.RegisterAccount, где сервисмы можем позаботиться о проверке новой учетной записи (проверка дублированного имени пользователя и т. д.), хэшировании pw и т. д.

Однако, чтобы добиться постоянства и достижимости, мне нужно добавить новую учетную запись в коллекцию SystemImplementation.Accountsчтобы он автоматически сохранялся в службе SystemImplementation (используя nhibernate, я могу использовать lazy = extra, чтобы при добавлении новой учетной записи в коллекцию автоматически не загружались все учетные записи)

Чтобы это произошло, я 'Возможно, мне потребуется создать учетную запись в AccountService, передать обратно несохраненную сущность клиенту, а затем вызвать клиент SystemImplementation.AssociateAccountWithSystemImplementation

, чтобы мне не нужно было вызывать службу SystemImplementation из AccountService (какпоправьте меня, если я ошибаюсь - это плохая практика)

Тогда у меня вопрос - неправильно ли я делю систему?Если так, как я должен разделить систему?Есть ли методология для определения способа разделения системы для SOA?Можно ли вызывать службу WCF из службы:

AccountService.RegisterAccount -> SystemImplementation.AssociateAccountWithSystemImplementation

Я беспокоюсь, что собираюсь начать строить систему на основе некоторыхантипаттерны, которые придут, чтобы поймать меня позже:)

Answer 1

У вас есть проблема с разделением, но вы не одиноки, все, кто принимает SOA, сталкиваются с этой проблемой. Как лучше организовать или разбить мою систему на соответствующие части?

Для меня Roger Sessions говорит больше всего на эту тему, а такие ребята, как Microsoft, очень внимательно слушают.

Документы, которые изменили мое мышление в этом, можно найти по адресу http://www.objectwatch.com/whitepapers/ABetterPath-Final.pdf,, но я действительно рекомендую его книгу Простые архитектуры для сложных предприятий.

В этой книге он вводит отношения эквивалентности из теории множеств и то, как они связаны с разделением договоров на обслуживание.

В двух словах,

Правила составления разделов можно обобщить в пять законов:

1. Разделы должны быть настоящими разделами. а. Элементы живут только в одном разделе.

2. Перегородки должны соответствовать рассматриваемой проблеме. а. Разделы минимизируют сложность только тогда, когда они соответствуют проблеме под рукой, например магазин одежды, организованный по цвету, будет иметь мало значения для клиенты ищут то, что хотят.

3. Количество подмножеств должно быть соответствующим. а. Исследования показывают, что в подмножество, добавляя больше подмножеств, тем самым уменьшая количество элементов в каждом подмножество, очень мало влияет на сложность, но уменьшает количество подмножества, таким образом увеличивая количество элементов в каждом подмножестве, кажется, добавить к сложности. Число, кажется, находится в диапазоне 3 - 12, с 3 - 5 быть оптимальным.

4. Размер подмножеств должен быть примерно равен а. Размер подмножеств и их важность в общем разделе должны быть примерно эквивалентно.

5. Взаимодействие между подмножествами должно быть минимальным и четко определенным. а. Снижение сложности зависит от минимизации количества и характер взаимодействий между подмножествами разбиения.

Не подчеркивайте слишком сильно, если сначала вы ошибаетесь, Манифест SOA говорит нам, что мы должны ценить эволюционное совершенствование, а не стремление к первоначальному совершенству.

Удачи

Answer 2

С SOA самое сложное - это выбор вертикальных функций.

Общие принципы ...

1) У вас не должно быть нескольких служб, работающих с одной и той же таблицей. Вам необходимо создать один сервис, который охватывает область функциональности, а затем действовать строго, не позволяя другим сервисам касаться этих же таблиц.

2) В отличие от этого, вы также хотите, чтобы каждый вертикальный срез был как можно более узким (но не уже!). Если вы можете избежать сложных, глубоких графов объектов, тем лучше.

То, как вы нарезаете свою функциональность, во многом зависит от вашего собственного уровня комфорта. Например, если у вас есть отношения между вашей «Статьей» и вашим «Автором», у вас будет соблазн создать граф объектов, представляющий «Автор», который содержит список «Статей», написанных автором. На самом деле было бы лучше иметь объект Author, предоставленный AuthorService, и возможность получать объект Article из ArticleService, основанный просто на AuthorId. Это означает, что вам не нужно создавать полный граф объектов автора со списками статей, комментариев, сообщений, разрешений и других загрузок каждый раз, когда вы хотите иметь дело с автором. Даже если NHibernate лениво загрузит соответствующие части этого для вас, это все еще сложный объектный граф.