Домен или прикладной уровень для некоторых классов в DDD

Question

Я работаю над проектом с использованием DDD, у меня есть несколько классов, и я не знаю, куда их поместить.

Домен о существующей игре. В этой игре есть основные понятия, такие как Character, SkillTree. Мой класс домена просто представляет эти понятия. Я не делал эту игру.

Мое приложение/проект о наличии программного обеспечения, которое представляет эти концепции, с некоторыми добавленными значениями. На данный момент имя и описание являются единственными возможными добавленными значениями (например, «Огненный маг» и «Мана зависима, будьте осторожны!»).

Вопрос 1: Имеет ли смысл иметь два класса, или я должен объединить их? В первом случае, где я должен поместить этот класс «с добавленной стоимостью (имя и описание)»? В прикладном уровне?

Вопрос 2: Я правильно говорю, что уровень домена представляет собой сферу знаний, над которыми я работаю, а уровень приложения представляет все вещи, которых нет в домене, но я хочу предоставить, как добавленная стоимость?

(поэтому, если моя программа просто представляет домен, уровень приложений является тонким, и если мое программное обеспечение обеспечивают много гостей функциональных доменов, на прикладном уровне толстая?)

Additonal информация 1: мой проект посвящен созданию симулятора персонажа. Поэтому, чтобы имитировать персонажа, я должен представлять его, а также все его зависимости. Ответ на мой домен должен представлять игру. Он содержит классы, такие как Character, с некоторыми свойствами (Life, Mana, Attack, Defense, Class) и некоторые enum (например, CharacterClass, в котором перечислены все доступные классы).

Теперь я хочу, чтобы мой собственный проект предоставил пользователю возможность создавать проект, представляющий характер игры. Проект также позволяет пользователю сохранять дополнительную информацию, такую ​​как название для текущего проекта, основное (и вторичное) оборудование, основное (и второе) skilltree. Аннотации также доступны для любого набора оборудования и деревьев навыков, поэтому пользователь может просто иметь встроенную заметку/пост-он. Набор инструментов вторичного оборудования и дерева навыков, аннотации не являются существующими концепциями в игре (и, следовательно, не существуют в моем домене).

В вопросе 1 «класс с добавленной стоимостью» представляет собой проект символа, который представляет собой совокупность нескольких информационных данных (оборудование персонажей, дерево навыков, аннотации и т. Д.). Его можно сохранить на физическую поддержку, открыть и отредактировать позже, если пользователь этого захочет.

Реформирование вопроса 1: У меня есть класс символов и класс CharacterProject. Класс CharacterProject представляет собой композицию из нескольких информационных данных. Но это характерно для моего приложения. Имеет ли смысл вкладывать его в прикладной уровень или в доменный уровень или где-то еще?

Answer 1

Для первого вопроса, я хочу прокомментировать и помочь вам с скромным руководством по проектированию. Смиренный смысл верьте этому на свой страх и риск: D.

При проектировании классов для любого уровня или любого типа программного обеспечения я обычно подхожу к нему с любовью обобщения (абстракция/сопряжение с интерфейсом и т. Д.). Вы упомянули, что у вас есть имя и описание, которые являются «значениями», которые будут добавлены к вашему так как «SkillTree» или «Character», спросите себя, можете ли вы обобщить классы имени и описания, например, интерфейс IAdditiveInformation.Если большинство из того, что эти два класса будут делать, могут быть разделены/заключены в контракты под обобщением IAdditiveInfromation, тогда вы знаете, что это также в вашем ядре домена. Если вы используете этот интерфейс в ядре своей модели домена и укажите все зависимости к этому интерфейсу, вам не придется отвечать на сложные и умозрительные вопросы дизайна, такие как

• Будет ли я добавлять дополнительные классы «значение»?
• Будет ли более класс «GamePart»?
• Как я могу создать классы «значение» и «GamePart», чтобы я мог реализовать их взаимодействие с минимальными усилиями.

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

• Если класс непосредственно связан с тем, что ваше программное обеспечение на как таким образом, что программное обеспечение учетной записи, связанной со счетами-фактурами, неотделимые и калекой без него, то этот класс находится в вашей модели домена слоя и в центре лука.
• Если класс работает с объектами в вашем ядре и только на вашем ядре домена, и они могут использоваться повторно, когда вы используете ядро ​​домена, такое как текущее ядро. Затем они являются вашими услугами домена.
• Если класс работает с вашими услугами домена и/или с вашим ядром домена, и он чувствует себя немного более специализированным для этого приложения. Тогда он, вероятно, входит в прикладной уровень. Для того, чтобы что-то находиться в прикладном уровне, помните, что эта функциональность должна быть критической для этого конкретного приложения в домене, а не для всего домена. Таким образом, вам нужна эта функциональность только для этого приложения.

Позвольте мне привести пример, чтобы сделать его немного понятным.

Представьте, что система отслеживания на основе GPS.

• В основе этого ядра лежит класс GPSTrackable (абстрактным классом, надеюсь).
• На уровне обслуживания домена есть класс, который работает/зависит от GPSTrackable, который является объектом запроса геолокации, где вы предоставляете GPS-бокс, и он возвращает вам GPS-треки в этом поле. Давайте назовем этот класс GPSTrackableQuery

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

Теперь с этим в нашем ядре луки,

• я могу сделать класс в прикладном уровне, что вызовы GPSTrackableQuery каждые 10 секунд и проверяют, есть ли какой-либо объект в непосредственной близости от военной базы для и вы получите систему безопасности на основе местоположения, если вы запустите это ядро ​​на телефоне каждого пользователя.
• Я могу создать класс на прикладном уровне, который вызывает GPSTrackableQuery, когда пользователь хочет отправлять массовые SMS или электронные письма людям, находящимся рядом с его магазином. Теперь я создал рекламную систему из одного и того же ядра домена.

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

Последнее примечание: вы также должны понимать, что размещение классов в слоях не имеет смысла. Мы просто помещаем их в «виртуальные» слои, чтобы они чувствовали свои обязанности и функциональность. Если у вас слишком много сомнений, просто поместите его где-нибудь, когда вы измените архитектуру или дизайн или реализацию, вы почувствуете, что это правильное размещение.

Для вашего второго вопроса.

На мой взгляд, ваше предложение верное. Единственное, что я могу прокомментировать, - я бы не использовал термин «сфера знаний» для доменного уровня (я предполагаю, что вы имеете в виду как ядро ​​домена, так и службы домена). Я рассматриваю ядро ​​домена как представление реальных знаний в компьютерных терминах или основных идей за ним.