Где начать при выполнении доменной модели?

Question

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

При рисовании модели домена я никогда не знаю, с чего начать:

1. Проектирование модели, как я считаю, что система должна быть. Это, если я моделирую человеческое тело, я начинаю с добавления классов концепций сердца, мозга, кишечника, желудка, глаз, головы и т. Д.
2. Начните с разработки того, какие случаи использования должны сделать. Это, если у меня есть случайный случай, который о том, чтобы сделать человеческое тело что-то глотать, я сначала нарисовал классы концепции для рта, горла, тотовое, кишечника и т. Д.

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

Спасибо

Answer 1

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

Вы можете использовать анемический подход (атрибуты плюс Getter и Setters), чтобы все могли просты и избежать шага записи бизнес-логики на том же шаге. С анемической моделью логика попадет в соответствующий класс услуг. Таким образом, вы можете рассмотреть возможность использования случаев позже.

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

Ответьте на поси по вопросу Элизиума ниже:

С точки зрения анализа, начиная с использования случаев (что), а затем переход к классу диаграммы (как) звучит как хорошее правило. Лично я бы сделал диаграмму последовательности (когда и кто?) После этого, как вам нужно знать, между какими процессами / объектами должны быть отправлены сообщения.

Помимо того, что мой взять на себя то, что UML - это просто способ моделировать систему / проект, а не методологию само по себе (в отличие от Merise, Rad, Rup, Scrum и т. Д.). Нет ничего останавливая кого-то, начиная с какой-либо диаграммы, пока у них есть достаточная информация, чтобы завершить ее. Фактически, они должны быть выполнены одновременно, поскольку каждая из диаграмм является другой перспективой одной и той же системы / проекта.

Итак, все во всем это зависит от того, как вы идете о анализе. В ходе моих исследований мне преподавали жесткий подход водопада, где вы выполняете полный анализ от начала до конца, прежде чем производить какой-код. Тем не менее, все могут отличаться на практике, так как императив может быть, чтобы произвести рабочее приложение в наименьшее время.

Например, я был представлен методологию Scrum в последнее время для упражнения, связанных с созданием веб-сайта, где люди могут опубликовать свои выдумывания. Поскольку было ограничение времени, и четкое видение того, что должно быть достигнуто, мы начались сразу с диаграммой классов голых костей для представления Доменная модель. Отказ Случаи использования были затем выведены из ряда макетных экранов, которые мы проходили.

Из памяти классы были история, глава, пользователем и категорией. Этот последний класс был показан в пользу более гибкого класса тегов. Когда вы себе представляете, полная классная диаграмма существующего проекта будет гораздо более сложным из-за применения доменного проекта и особенности языка программирования Java.

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

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

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

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

Answer 2

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

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

Answer 3

Я думаю, что место для начала было бы тем, что чувствует себя логичным и комфортно. Вероятно, лучше всего начать с использования случаев, поскольку они дают вам четкое направление и цели, а также помогут избежать ситуаций Yagni. Учитывая, что вы должны пытаться разработать сильную модель домена, она не должна иметь значение, так как вся картина домена важна.

Answer 4

Я хотел бы поделиться своим опытом для таких ситуаций. Я обычно начинаю с написания тестов и кода. И попробуйте прикрыть один конец, чтобы закончить корпус. Это дает мне достаточно, достаточно идеи о проблеме и в конце у меня также есть что-то работать со мной, которым я могу показать случай моего клиента. Большую часть времени последующие истории опираются сверху предыдущего, но это также происходит со мной, что последующие истории требуют изменения в предыдущей модели, которую я придумал. Но это не влияет на меня, так как у меня уже есть хорошее тестовое покрытие. Таким образом, я придумал модель, которая соответствует текущей проблеме, а не модель, которая отображает реальный мир.

Answer 5

Вы начинаете с бизнес-требований, которые могут быть формализованы или нет. Если формализовано, вы будете использовать использование диаграмм корпуса.

Например, здесь используются диаграммы Case для приложения электронной коммерции:http://skuml.com/blog/e-commerce/

http://skuml.com/files/2010/07/e-commerce-use-case.jpg. http://skuml.com/files/2010/07/e-commerce-use-case2b.jpg.

Из этих случаев использования вы можете, естественно, вывести бизнес-объекты: Продукт, категорию продукта, корзина для покупок, ... Это начинает готовить классы диаграмм.

Это лучшая практика во многих методологиях, но это также просто здравый смысл и естественный.

Answer 6

Краткий ответ

Выберите корпус на использование, нарисуйте некоторую диаграмму для совместной работы (и диаграмму классов), чтобы реализовать участие доменных объектов. Концентрат только на этих объектах участвовал, чтобы выполнить цель использования. Напишите тестовое дело TDD, чтобы установить ожидание и постепенно моделировать свои классы домена для удовлетворения ожиданий. Тдd Очень полезно понимать ожидаемое поведение, и оно помогает получить модель чистой домена. Вы увидите, что ваш домен развивается постепенно вместе с ожиданиями TDD.

Длительный ответ

Мой личный опыт с DDD было непросто. Это было потому, что у нас не было необходимых оснований в первую очередь. У нашей команды было много слабых очков в разных областях; Требования не были пойманы должным образом, и у нас был только представитель клиента, который не был очень полезным (не вовлечен). У нас не было правильного плана выпуска, и разработчики не хватало объектных ориентированных концепций, лучших принципов и так далее. Основная проблема, которую мы провели так много времени на попытке понять логику домена. Мы набросали много классных диаграмм, и мы никогда не получили доменную модель, поэтому мы перестали делать это и узнать, что пошло не так. Проблема заключалась в том, что мы слишком сложно понять, чтобы понять логику домена и вместо того, чтобы мы сделали допущения на требования. Мы решили изменить наш подход, мы применили TDD, мы начали писать ожидаемое поведение и записали модель домена для удовлетворения ожиданий TDD. Иногда мы застряли писать тестовые случаи TDD, потому что мы не поняли домен. Мы сразу разговаривали с представителем клиента и пытались получить больше входов. Мы изменили нашу стратегию выпуска; Применяемая гидродобывающая методология и часто высвобождает, чтобы мы получили реальную обратную связь от конечного пользователя. Однако необходимо для обеспечения ожидания конечного пользователя на правильном уровне. Мы использовали на основе обратной связи, а таким образом, модель домена развивалась постепенно. Впоследствии мы применили проектные шаблоны для повышения повторного использования и ремонтопригодности. Моя точка зрения здесь, что только DDD не может выжить, мы должны построить экосистему, которая охватывает домен, разработчики должны иметь сильные концепции ООП и должны оценить тест TDD и единиц. Я бы сказал, что DDD сидит на вершине всех методов и практики ООП.