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

Question

У меня есть несколько общих вопросов о дизайне фреймворка.

Я создаю API для приложения iPhone на C # .NET (framework 3.5) и SQL 2008 (используя LINQ). Я следовал шаблону «Управляемый доменом» (в книге) и иметь следующую структуру папок:

Core
- DataAccess
--Impl
-Domain
-Impl

Ядро - это моя основная библиотека API - мои библиотеки DLL. DataAccess содержит интерфейсы доступа к данным DataAccess.Impl содержит репозитории (LINQ to DB) Домен содержит большинство моих типов данных и свойств. Impl содержит мои услуги (т.е. AccountService.cs, EmailService.cs)

Теперь в качестве упражнения я добавил службу Windows в этот проект. и я пытаюсь вызвать функциональность из DLL в этом сервисе. МОЙ ВОПРОС: какой слой я должен показывать другим приложениям? а что должно оставаться скрытым?

• Должны ли классы обслуживания из папки Impl быть тем, что видят программисты?
• Или хранилища из DataAccess.Impl?
• Или я должен просто выложить все это на усмотрение программистов? Как это выглядит теперь это кажется немного запутанным.

Когда я начал читать о DDD, я предполагал, что репозитории будут скрыты и доступны для классов обслуживания, но я нахожу, что мне нужно позвонить функциональность от обоих в моем клиенте. Я разработал это неправильно?

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

using Company.Product.ProductCore.Core.DataAccess.Impl 
using Company.Product.ProductCore.Core.Domain 
using Company.Product.ProductCore.Core.Impl

Это кажется многословным. Глядя на библиотеки Microsoft, они, кажется, придерживаются двухуровневой соглашение - (System.Linq, System.Text и т. д.). Наличие Company.Product.ProductCore.Core.Impl кажется грязным и на самом деле не говорит программисту, что делает это пространство имен (но это это то, что было предложено в примере, который я прочитал). Есть ли здесь лучшая практика?

Ваши предложения (и любые примеры) очень ценятся.

Спасибо.

Answer 1

Если я не ошибаюсь, вы задаете два вопроса:

1. Как структурировать приложение DDD?
2. Как насчет этих длинных имен пространства имен?

Мой ответ довольно длинный - я позволил себе разделить его на два ответа.

Это ответ на второй вопрос:

2.Как насчет этих длинных имен пространства имен

Я не думаю, что длинные имена пространства имен обязательно являются грязными.ИМХО, что выглядит грязно в ваших именах:

• повторение слов "Product" и "Core"
• Использование общего термина "Impl"

Первым улучшением может быть:

// The Domain objects go here;
MyCompany.MyProduct.Core.Domain;  
// DataAccess interfaces go here:
MyCompany.MyProduct.Core.DataAccess;
// a Linq implementation of the DataAcces interfaces go here:
MyCompany.MyProduct.Core.DataAccess.LinqImpl; 
// The Core service go here:
MyCompany.MyProduct.Core.Services;
// Some general purpose infrastructure goes here (e.g. emailing code)
Mycompany.MyProduct.Infra;

Более того, я считаю, что использование названия коммерческого продукта (например, MyProduct) в структуре кода плохо (что если маркетинг выбирает другое имя?);Мне нравится использовать имя логических подсистем вместо этого.Давайте предположим, что вы строите систему проката автомобилей.Тогда CarRental будет считаться основной функциональностью этого приложения.Затем я использовал бы следующую структуру пространства имен (Serra - название моей компании):

// For classes Customer, Account, Car
Serra.CarRental.Domain;    
// I use Dao as a general abbreviation for "Data Access Objects"
// Dao interfaces go here:
Serra.CarRental.Dao;     
// Linq implementation for Dao interfaces  
Serra.CarRental.Dao.Linq;
// For Services specific to the car rental domain: 
// AccountService and RentalService and CarAvailabilityService
Serra.CarRental.Services;  
// For UI objects (not relevant in you situation?)
Serra.CarRental.UI;
// general service code; ignorant of the CarRental domain (e.g. an EmailService)
Serra.Infra.Service;       

Answer 2

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

По моему скромному мнению, то, что должно быть открыто, еще не существует, то естьэто, скажем, статический класс, если мы рассмотрим шаблон проектирования Façade, который раскрывает возможности и функциональности вашей подсистемы библиотеки.

Шаблон проектирования Façade объяснил:

1. Шаблон фасада - (Банда четырех) ;
2. Шаблон фасада (Википедия) .

Итак, в конце концов, что должен делать ваш код?Просто представьте, что необходимо, что вам следует знать, поскольку вы единственный, кто знает о системе, которую вы разрабатываете.

Короче говоря, я часто использую шаблон Фасада, чтобы изолировать своиклассы, реализации и несколько связанных подсистем под капотом фасада.Давайте рассмотрим, мы являемся совершенно новым дилером автомобилей.Этот фасад будет отличными окнами, которые позволят вам увидеть машины, выставленные в выставочном зале.Вы должны думать о том, что выставляет этот фасад.Это выставляет только автомобили?

На мой взгляд, этот фасад выставляет автомобили, которые вы сможете купить, одолжить, купить, отремонтировать автомобиль, купить другие сопутствующие аксессуары и т. Д. Аксессуарызатем должны быть разоблачены, но только то, что нужно.То же самое с другими предметами, такими как автомобиль.То есть вы можете захотеть предоставить только интерфейс и сохранить реализацию для себя, чтобы через ваш фасад, когда вам нужно было вернуть ICar или IAccessory, вам нужно было создать их экземпляр с помощью класса объекта реализации, затем верните экземпляр интерфейса через ваш фасад.Тем не менее, пользователю не нужно знать, что происходит под капотом, но только то, что если он хочет автомобиль, он должен заказать его через ваш фасад.Точно так же, как вы не пойдете покупать Mazda 3 на Mercedes Benz.Вы будете работать с правильным фасадом.С другой стороны, разные автодилеры могут быть только подсистемами, а значит, это своего рода фабрики.Затем вы спрашиваете у фасада автомобиль с этой и той же спецификацией, и фасад должен знать, какой экземпляр ICar нужно вернуть, чтобы обменять на то, что вы просите его предоставить.

Надеюсь, это поможет в любом случае!=)

Answer 3

Я сомневаюсь, что пользователи вашего приложения увидят это.Первое, что вам нужно, это функциональность.Это то, что вы продадите в конце.

Также вам нужно сделать расходы на обслуживание как можно ниже.И вот как организован ваш код.Второе - минимизировать расходы на обслуживание.

Поэтому, чтобы решить, как организовать свое решение, вам необходимо ответить на несколько вопросов:

1. Как подобранная структура поможет мне выполнить обслуживание и добавить новые функции?
2. Как это поможет новым разработчикам начать кодирование в моем решении?
3. Являются ли все эти имена сборок / папок / классов узнаваемыми и описательными?
4. Вопросы, которые я забыл.

Это ваши цели.Но не те правила, которые вы ищете.Вы можете выбрать любые имена, если новый разработчик их поймет.

Возможно (в качестве эвристики и если вы используете некоторые инструменты рефакторинга, такие как Resharper или Refactor! Pro), вы можете начать с одной сборки и одного пространства имен.Во время разработки вы увидите, как вы можете изменить структуру вашего проекта, чтобы лучше соответствовать вашим потребностям.Затем выполните рефакторинг.

Пойдите, посмотрите этот разговор в 38: 18-39: 45 (~ 1,5 минуты).Есть хорошая практика о том, как ответить на некоторые вопросы.