Цель C Домен-управляемый дизайн

Question

Обычно при программировании на C # я проектирую свой проект по принципам, управляемым доменом.Я новичок в программировании в Objective C для iPhone, и мне было интересно, есть ли у кого-нибудь примеры проектов или кода, которые используют принципы проектирования на основе домена в Objective C. Я ищу примеры использования Business Objects и т. Д.Спасибо.

Answer 1

Существует вероятность того, что вы неправильно поняли, каковы принципы доменного управления.DDD - это набор руководящих принципов, он больше касается того, как вы думаете и как вы подходите к решению проблем, в основном он не зависит от технологий.Ничто не мешает вашему дизайну руководствоваться доменом, а не технологией, если вы пишете код Objective C (лично мне понравился тот факт, что вы должны называть аргументы, потому что он, по моему мнению, делает код более читабельным).Вопрос, вероятно, касается технологий, которые обычно поддерживают (но не определяют) DDD: ORM, DI, модульные тесты.И эта часть ИМХО не очень хороша (исходя из недолгого и относительно устаревшего опыта).Вместо использования ORM вы обычно используете Базовые данные , которые являются персистентным графом объектов, который, как предполагается, еще лучше в теории, потому что вы не имеете дело с «реляционной» частью.Однако я помню, что Core Data накладывает определенные ограничения на мою объектную модель, которых я хотел бы избежать в других средах.Не могу говорить за DI, но модульное тестирование было проблемой (в 2010 году), и я слышал, что это все еще в 2012 году.

Суть в том, что вам придется уточнить свой вопрос, разделить его ивозможно, спросите об этом в разделе Objective-C.

Answer 2

Я удивлен, что никто не упомянул, как анти-DDD CoreData является. Даже с приложениями в стиле CRUD я всегда стараюсь кодировать стиль DDD. Первое, что вы заметите, - это широкое использование CoreData в Какао, особенно на Mac.

XCode и Cocoa способствуют использованию CoreData для привязок. Однако CoreData заставляет вас все время кодировать базу данных, а не модель домена. Действительно, вы не можете переименовать один атрибут объекта домена без принудительного переноса всей базы данных.

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

Answer 3

Я тоже пришел из C #, и после полугода работы в ObjC я должен сказать, что, безусловно, можно полностью следовать принципам DDD в Objective-C.Частично из-за статической / динамической гибридной природы языка smalltalk-ish.

Например, вы можете очень легко «перехватить» сообщение, отправленное объектам (так называемый перехват вызовов методов), просто переопределив несколько методов, которые делаютDI и модульное тестирование очень легко выполнить, если вы понимаете, что я имею в виду.

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

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

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

Так что я бы сказал, что в ObjC вполне возможно / даже проще следовать принципу DDD.

Что касается примеров, я никогда не видел ни одного.Но, конечно, нетрудно следовать той же структуре, которую вы используете в проектах C # (не копируйте их, а смоделируйте аналогично).Изучение технологий, о которых я упоминал, также поможет вам.