Изучить корпоративную архитектуру за 24 часа было бы идеально
Я бы не стал верить этому, даже если бы он существовал :) Имейте в виду, что не существует единственного верного способа создания архитектуры.предприятие.Нет единого шаблона, который лучше всех остальных в каждой ситуации.Ваше предприятие найдет свой путь.Будут компромиссы, будут компромиссы и т. Д. Некоторые вещи будут иметь смысл для разработчиков, некоторые вещи будут иметь смысл для пользователей, некоторые вещи будут иметь смысл для управления ... Но все должно иметь смысл для бизнеса.
При этом, примите любой совет здесь с недоверием.
Хорошее эмпирическое правило при организации вашего кода - спросите себя "чей кодэтот?"То есть для всего, что вы пишете, какая часть общей системы заботится об этом?Вот где этот код принадлежит.Если это код, который определяет поведение пользовательского интерфейса, он не входит в DAL.Если это код, который поддерживает основную бизнес-логику, он не принадлежит пользовательскому интерфейсу.И так далее.
Один подход, который имеет тенденцию работать для меня, - это Domain Driven Design .Как процесс, я склонен подходить к этому так:
- Определить бизнес-модели.Именно здесь все должно быть максимально разумным для большинства людей.Это ваш "вездесущий язык".Все в компании знают, что такое
Order.Они все знают, что должно произойти, когда вы звоните Order.Submit() на одного.Это ваш BLL, и все, что его волнует, это бизнес-логика.Не должно быть никаких проблем с пользовательским интерфейсом, никаких проблем с сохранением данных, ничего подобного.Это базовая сборка, которая определяет бизнес-логику и повторно используется в любом приложении в домене. - Определите сохранность данных.Здесь ваши бизнес-модели встречаются с базой данных.Это может быть одна база данных, несколько баз данных, набор баз данных / файловых систем / служб / и т. Д. И т. Д.(Теперь истинное постоянное невежество является чем-то вроде святого Грааля доменного проектирования. Возможно, вашим моделям придется пойти на некоторые компромиссы для вашей инфраструктуры. Это происходит.)
- Определите ваши приложения.Это могут быть пользовательские интерфейсы, веб-сервисы и т. Д. С точки зрения ядра домена это не имеет значения.Бизнес-логика - это бизнес-логика, она поддерживается во всем домене, независимо от того, что ее использует.Если конкретное приложение должно переопределить бизнес-логику определенным образом, сделайте это в приложении.Представление данных пользователям, сбор данных от пользователей - вот что заботит приложения.
Теперь некоторые приложения захотят использовать больше настраиваемых объектов.Может быть, одно приложение хочет использовать класс Order, но каким-то образом изменить его.Возможно, даже объединить это с другими классами.Это отлично.Это проблема этого приложения.Внутренне у него будет свой собственный мини-домен, в котором он определяет свои пользовательские модели и имеет свой собственный DAL для преобразования этих моделей в / из моделей базового домена.Это было бы больше «ViewModel» в том смысле, что оно принадлежит непосредственно этому приложению, а не бизнес-логике.
Думайте о каждом приложении как о миниатюрном домене.С точки зрения всего домена каждое приложение является частью пользовательского интерфейса.С точки зрения самого приложения, общий домен - это инфраструктура, стоящая за постоянством приложения.
В общем, вы можете увидеть, что мои проекты Visual Studio организованы так:
Project: MyBusiness.Domain
Folder: Models
Folder: Services
Folder: Repositories
Project: MyBusiness.Infrastructure.DAL
Reference: MyBusiness.Domain
Folder: Repositories
Project: MyBusiness.Infrastructure.AddressService
Reference: MyBusiness.Domain
Folder: Services
Project: MyBusiness.Application.Intranet
Reference: MyBusiness.Domain
Folder: Controllers
Folder: Views
Folder: ViewModels
Project: MyBusiness.Application.CustomerIntegrationService
Reference: MyBusiness.Domain
Folder: ServiceDTOs
И такна.Я использую контейнер IoC ( StructureMap - мой личный фаворит, но есть много других), чтобы связать зависимости.За исключением Моделей, почти все в проекте Domain является просто интерфейсом.Может быть несколько проектов инфраструктуры, реализующих эти интерфейсы, и каждый проект приложения может настроить, какие из них он хочет использовать при подключении контейнера IoC.
Этот подход довольно четко разделяет проблемы.У вас может быть столько приложений, использующих ядро домена, сколько вы хотите, и вы можете иметь столько реализаций зависимостей (включая реализации тестовых макетов), сколько захотите.
Я надеюсь, что это помогло, а не просто закончилосьпо некоторой касательной.Признаюсь, немного сложно представить, что именно вы задаете в этом вопросе.