N-слойная архитектура

Question

Я нахожусь в ситуации, когда мне нужно спроектировать и внедрить систему с нуля. У меня есть несколько вопросов об архитектуре, о которых я хотел бы услышать ваши комментарии и мысли.

Краткая информация о проекте: это веб-приложение, ориентированное на данные.

Приложение будет построено на основе Microsoft .NET Framework 4.0 с базой данных MS SQL SERVER 2008.

Требование:

1. Богатый пользовательский интерфейс и надежный
2. Поддержка нескольких устройств (каждый браузер и на каждом устройстве)
3. Слабо связанный

Ниже приведена архитектурная схема, которую я построил:

Брифинг по архитектуре

1. Уровень представления: HTML5/ASP.NET MVC + JQuery (веб-приложение для поддержки нескольких устройств в первой версии)
2. Распределенные сервисы: WCF (XML/JSON/JSONP)
3. Уровень домена (Business Layer): вся бизнес-логика
4. Постоянство данных (уровень DAL): Entity Framework 4.0 с базой данных в первую очередь. Объекты POCO генерируются и выделяются с использованием шаблона T4
5. Инфраструктурный уровень: содержит общие библиотеки, такие как объекты POCO, обработка исключений, ведение журнала и т. Д.

Мои проблемы:

1. Как приложение должно быть построено слабосвязанным, так и в будущем, если требования бизнеса будут расти, новые модули могут быть легко подключены без ущерба для архитектуры. Поэтому я подумал об использовании шаблона Repository вместе с IoC и DI (может быть Unity/Ninject/Sprint.NET или любой другой)
2. WCF с поддержкой XML и JSON
3. Уровень распределенного обслуживания для размещения IoC и DI
4. Обработка исключений и ведение журнала с использованием Enterprise Library 5.0

Ищете ценные комментарии и предложения. Если я делаю что-то не так, пожалуйста, направьте меня в правильном направлении.

Answer 1

Я бы предложил следующий комментарий: с самого начала ваш подход создаст тесную связь. Это идет вразрез с вашим требованием № 3 "Слабосвязанное"

На вашей диаграмме вы определили два модуля. Основной модуль и Модуль 2. Я думаю, что эти два модуля довольно сильно отличаются друг от друга. Под этим я подразумеваю, что вы можете разработать их полностью отдельно, а затем подключить к ним, потому что проблемы бизнеса, которые они решают, различны.

Тем не менее, ваш текущий архитектурный подход:

• Соединяет основной модуль и данные модуля 2 в одну базу данных
• Объединяет бизнес-объекты основного модуля и модуля 2 в один бизнес-уровень
• Соединяет основной модуль и модуль 2 на одном уровне обслуживания
• Пары развертывания и управления основного модуля и модуля 2

Что может стоить рассмотреть: собрать основной модуль и модуль 2 в виде отдельных вертикальных служебных стеков.

Я имею в виду, что основной модуль и модуль 2 становятся основным обслуживанием и обслуживанием 2

Каждый сервис имеет свою собственную базу данных, свой бизнес-уровень, свой сервисный уровень и собственные компоненты пользовательского интерфейса.

Однако это вызывает обеспокоенность: как Main Service и Service 2 могут работать вместе для создания моего продукта?

Для решения этой проблемы:

1. На пользовательском интерфейсе вы объединяете ваш внешний интерфейс, используя код на стороне клиента, чтобы загрузить ответы из главной службы и службы 2 в одно представление.

2. В бэкэнде вы используете общедоступную подписку на сообщения, чтобы позволить Главной службе подписаться на события, происходящие в Службе 2, и наоборот.

Это приведет к созданию приложения, созданного с нуля поверх слабо связанных вертикальных служебных стеков, которые поддерживают согласованность посредством асинхронного обмена сообщениями.

Если затем вам нужно добавить новый модуль в ваше приложение, вы можете создать новый стек услуг, который поддерживает желаемую возможность, и подключить его практически без изменений к другим стекам (в идеале, это единственная причина для изменения существующих стеков). было бы, что они хотят подписаться на события из нового модуля).

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

Answer 2

Как получилось, что диаграмма архитектуры не использует уровень домена для ASP.NET?

Мне кажется, что вы, возможно, занимаетесь чрезмерной архитектурой своего приложения. Кроме того, несмотря на то, что поддержка 6 (или около того) различных технологий переднего плана выглядит великолепно, усилия по их поддержке будут ужасными. Я бы придерживался одной технологии для внешнего интерфейса - скорее всего, HTML5 с клиентской стороной MVC или аналогичной.

Answer 3

Имеет смысл, что интерфейсы WPF, WinForm и т. Д. Должны вызывать уровень WCF. Я предполагаю, что это бизнес-требование иметь несколько интерфейсов, в противном случае, если у вас может быть только один интерфейс, адаптивный веб-интерфейс является наиболее гибким выбором.

Тем не менее, я не думаю, что ваш MVC UI должен использовать слой WCF. Это может вызвать доменный слой напрямую. Это было бы быстрее и удалить бессмысленный слой.

Очевидно, это будет работать только до тех пор, пока вы не добавите никакой логики в свой слой WCF. И слой WCF действительно не должен иметь никакой логики.

Вы также заявляете, что хотите разместить IoC и DI на уровне распределенного сервиса. Это не имеет большого смысла с точки зрения вашего пользовательского интерфейса MVC. Вам нужно будет использовать DI в проекте MVC, чтобы вы могли модульно протестировать контроллеры.

Answer 4

Глядя на вашу диаграмму, у меня есть пара моментов, которые мне не совсем понятны:

• Где модель домена? Доменное ядро ​​или "модель" в постоянном слое?
• Как уровень домена взаимодействует с уровнем доступа к данным? Взаимодействие не такое четкое, как между уровнем службы / приложения и уровнем домена.
• В чем разница между хранилищем на уровне домена и хранилищем на уровне доступа к данным? Обычно я делаю различие между наличием "репозиториев моделей" на уровне домена, которые действуют на объекты модели домена, и "шлюзов данных" на уровне доступа к данным, которые действуют на DTO.
• Что такое доменное ядро? Это реализация транзакций прикладного уровня?
• Должна ли быть дальнейшая абстракция структуры персистентности? (EF)