Соглашения об именовании проектов Biztalk

Question

При запуске проекта BizTalk я обычно следую соглашениям об именах, найденным here. Где вы называете свои проекты и что-то новой сборки, как:

MyCompany.MyProject.Orchestrations.dll 
MyCompany.MyProject.Schemas.dll 
MyCompany.MyProject.Pipelines.dll 
MyCompany.MyProject.Transforms.dll 
MyCompany.MyProject.PipelineComponents.dll 

пару вопросов для других BizTalk людей:

1) Обычно я иметь больше чем один проект со схемами или необходимости разделения схем. Вы придерживаетесь их в отдельных сборках, и если да, то какое соглашение вы следуете за именованием проекта/сборки. Если нет, вы вставляете их в подпапку в одной сборке.

2) Я считаю, что может быть неправильно, что это было своего рода соглашение BizTalk, чтобы назвать проект и сборку одинаковыми, как указано выше. Я думал об уходе от имен проектов так же, как и полное имя сборки, поэтому у меня может быть проект с именем «Карты», и его сборка называется MyCompany.MyProject.Maps. Другие делают это?

Answer 1

Начиная с БПСОМ 2009 мы назвали наши проекты и сборки в соответствии с приложением к которому они принадлежат плюс необязательное субприложение или касаются сфер:

MyCompany.Biz.MyFirstApp.dll 
MyCompany.Biz.MyFirstApp.Util.dll 
MyCompany.Biz.MyFirstApp.ConcernOne.dll 
MyCompany.Biz.MySecondApp.dll 

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

Наша главная цель заключалась в том, чтобы разделить источники и целевые системы, чтобы избежать ссылок на ссылки. Мы добились этого представлю "основные" компоненты для всех проблем, мы имеем дело с:

БПС применение MyFirstApp

MyCompany.Biz.MyFirstApp.OrderProcessing.dll 
MyCompany.Biz.MyFirstApp.Util.dll 

БПС приложения CORE

MyCompany.Biz.CORE.OrderProcessing.dll 

БПС приложение MySecondApp

MyCompany.Biz.MySecondApp.OrderProcessing.dll 

Оба MyFirstApp и MySecondApp будут ссылаться на схемы в CORE.OrderProcessing.

---

Update

MyCompany.Biz.MyFirstApp.OrderProcessing будет содержать схему сообщений для документов входящих заказов и карту для отображения тех, в базовую схему сообщения заказа (содержится в MyCompany. Biz.CORE.OrderProcessing). При необходимости он может также содержать оркестровку для приема сообщений и (получения) компонентов конвейера (например, при работе с плоскими файлами).

MyCompany.Biz.MySecondApp.OrderProcessing будет содержать схему сообщений для исходящих документов и карту для отображения из схемы сообщения ядра порядка (для исходящих).

В этом базовом макете CORE будет просто контейнером для внутренних схем сообщений, но он будет лучшим местом для добавления информации в ваши документы заказа - например, оркестровка, которая присуждает глобальную скидку для клиентов класса А (бизнес-правила !). Короче говоря, любой шаг, который вы делаете дважды или даже больше, когда вы отправляете или получаете сообщения, и вы не хотите прикасаться к изменениям входящих или исходящих сообщений или добавлению нового приложения.

Answer 2

Вот замечательный BizTalk Naming Conventions гид от Скотта Colestock