Может кто-нибудь, пожалуйста, объясните (в сжатых терминах), что такое дизайн, управляемый доменом? Я вижу этот термин довольно много, но на самом деле не понимаю, что это такое или как он выглядит. Как он отличается от дизайна, не связанного с доменом?
Кроме того, может кто-нибудь объяснить, что такое объект домена? Как домен отличается от обычных объектов?
EDIT:
Как кажется, это лучший результат в Google, и мой ответ ниже - нет, пожалуйста, обратитесь к этому гораздо лучшему ответу:
fooobar.com/questions/47536/...
OLD ANSWER (не так полно:))
Чтобы создать хорошее программное обеспечение, вы должны знать, что это программное обеспечение это все о. Вы не можете создать систему банковского программного обеспечения, если только вы не хорошо понимают, что такое банковское дело, нужно понять сферу банковской деятельности.
От: Проект, управляемый доменом Эриком Эвансом.
В этой книге довольно неплохо описать DDD.
Зарегистрируйтесь, чтобы загрузить резюме книги, или загрузить сводку непосредственно.
Domain Driven Design - это методология и рецепт процесса для разработки сложных систем, целью которых является отображение действий, задач, событий и данных в проблемной области в технологические артефакты домена решения.
Акцент проекта Driven Design заключается в понимании проблемной области, чтобы создать абстрактную модель проблемной области, которая затем может быть реализована в определенном наборе технологий. Разработка под управлением домена в качестве методологии дает рекомендации о том, как эта разработка модели и технология могут привести к созданию системы, которая удовлетворяет потребности людей, использующих ее, а также быть надежной перед лицом изменений в проблемной области.
На стороне процесса разработки Driven Driven Design участвует сотрудничество между экспертами домена, людьми, которые знают проблемную область, и экспертами по дизайну/архитектуре, людьми, которые знают домен решения. Идея состоит в том, чтобы иметь общую модель с общим языком, так что, поскольку люди из этих двух разных доменов с двумя разными перспективами обсуждают решение, они фактически обсуждают общую базу знаний с общими понятиями.
Отсутствие общего понимания проблемной области между людьми, нуждающимися в конкретной системе, и людьми, которые проектируют и внедряют систему, по-видимому, является основным препятствием для успешных проектов. Domain Driven Design - это методология для устранения этого препятствия.
Это больше, чем наличие объектной модели. Основное внимание уделяется общему обмену сообщениями и улучшению сотрудничества, чтобы можно было обнаружить фактические потребности в проблемной области и создать соответствующее решение для удовлетворения этих потребностей.
Проект с поддержкой домена: Хороший и сложный содержит краткий обзор с этим комментарием:
DDD помогает обнаружить архитектуру верхнего уровня и информировать механика и динамика домена, которое программное обеспечение должно реплицировать. Конкретно это означает, что хорошо выполненный DDD-анализ минимизирует недоразумения между экспертами домена и программным обеспечением архитекторов, и это уменьшает последующее количество дорогостоящих запросов для изменения. Разделив сложность домена в меньших контекстах, DDD избегает принуждения архитекторов проекта к разработке раздутого объекта модель, в которой много времени теряется при разработке детали реализации - отчасти потому, что количество часто приходится превышать размеры белой доски конференц-зала.
Также см. эту статью Архитектура доменного проектирования для архитектуры сервисов, которая представляет собой краткий пример. В статье представлено следующее миниатюрное описание Domain Driven Design.
Дизайн, основанный на домене, защищает моделирование, основанное на реальности бизнес, имеющий отношение к нашим прецедентам. Поскольку сейчас он становится старше и уровень шумихи снижается, многие из нас забывают, что подход DDD действительно помогает понять проблему и разрабатывать программное обеспечение в общее понимание решения. При создании приложений, DDD говорит о проблемах как о доменах и поддоменах. Он описывает независимые этапы/области проблем как ограниченный контекст, подчеркивает общий язык, чтобы говорить об этих проблемах, и добавляет много технических понятия, подобные объектам, объектам ценности и общим правилам корней для поддержка реализации.
Мартин Фаулер написал ряд статей, в которых упоминается Domain Driven Design как методология. Например, эта статья BoundedContext дает обзор концепции ограниченного контекста из Domain Driven Development.
В те молодые годы нам советовали создать единую модель весь бизнес, но DDD признает, что мы узнали, что "всего унификация модели домена для большой системы не будет допустимый или рентабельный" 1. Поэтому DDD делит большую система в ограниченные контексты, каждая из которых может иметь единую модель - по существу способ структурирования MultipleCanonicalModels.
Вы МОЖЕТЕ ТОЛЬКО понять дизайн, управляемый доменом, сначала поняв, что является следующим:
Что такое домен?
Поле, для которого построена система. Управление аэропортом, страховые продажи, кафе, орбитальный полет, вы называете это.
Нет ничего необычного в том, что приложение охватывает несколько разных доменов. Например, система розничной торговли в Интернете может работать в областях доставки (выбор подходящих способов доставки, в зависимости от товаров и места назначения), ценообразования (включая рекламные акции и индивидуальные цены, скажем, по местоположению) и рекомендаций (вычисление связанных продукты по истории покупки).
Что такое модель?
"Полезное приближение к рассматриваемой проблеме". - Джерри Суссман
Класс Employee не является реальным сотрудником. Он моделирует настоящего сотрудника. Мы знаем, что модель не отражает все о реальных сотрудниках, и это не главное. Это означало только захватить то, что нас интересует в текущем контексте.
Разные домены могут интересоваться разными способами для моделирования одной и той же вещи. Например, отдел оплаты труда и отдел кадров могут моделировать сотрудников по-разному.
Что такое модель предметной области?
Модель для домена.
Что такое доменно-управляемый дизайн (DDD)?
Это подход к разработке, который глубоко ценит модель предметной области и связывает ее с реализацией. DDD был придуман и изначально разработан Эриком Эвансом.
Отобранный отсюда
Вот еще одна хорошая статья, которую вы можете проверить на Domain Driven Design. если ваше приложение является чем-то серьезным, чем назначение колледжа. Основная посылка - это структура вокруг ваших объектов и сильная модель домена. Различия между службами, которые обеспечивают связанные с инфраструктурой вещи (например, отправка электронной почты, сохраняющиеся данные) и услуги, которые фактически выполняют те вещи, которые являются вашими основными бизнес-требованиями.
Надеюсь, что это поможет.
Как и в TDD & BDD, вы/команда больше внимания уделяете тестированию и поведению системы, чем реализации кода.
Аналогично, когда системный аналитик, владелец продукта, команда разработчиков и, разумеется, код - сущности/классы, переменные, функции, процессы пользовательских интерфейсов взаимодействуют с использованием одного и того же языка, который называется доменно-управляемым дизайном
DDD - это мыслительный процесс. При моделировании дизайна программного обеспечения вам необходимо держать в центре внимания бизнес-область/процесс, а не структуры данных, потоки данных, технологии, внутренние и внешние зависимости.
Есть много подходов к модели системной с использованием DDD
В очень наивных словах, объект, который
Я верю, что следующий PDF даст вам большую картину. Дизайн, управляемый доменом, Эрик Эванс
ПРИМЕЧАНИЕ. Подумайте о проекте, над которым вы можете работать, примените мелочи, которые вы поняли, и ознакомьтесь с лучшими практиками. Это также поможет вам развить ваши способности к проектированию архитектуры микросервисов.
Когда мы сталкиваемся со сложными проблемами, мы обычно пытаемся понять отдельные части сложности. Разлагая проблему, мы превращаем ее в более понятные и управляемые части. Это не отличается в мире разработки программного обеспечения. Хотя в течение многих лет к процессу разработки программного обеспечения применялись рецепты, похожие на водопад, в конце концов преобладали эвристические и основанные на опыте методы оценки (планирование покера, определение размера футболок) и гибкие процессы. Как и в реальной жизни, мы постарайтесь сосредоточиться не на деталях всего процесса, а на том, чтобы понять общее путешествие, взглянув на наши последние выступления. Интересная методика разработки программного обеспечения для понимания и решения сложных задач - это Domain Driven Design (DDD).