Предметно-ориентированное проектирование: различия между версиями

[непроверенная версия]

[отпатрулированная версия]

Содержимое удалено Содержимое добавлено

Линейный

Текущая версия от 23:24, 11 октября 2024

Предметно-ориентированное проектирование (реже проблемно-ориентированное, англ. domain-driven design, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями предметных областей. В эти модели входит бизнес-логика, устанавливающая связь между реальными условиями области применения продукта и кодом.

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

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

Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»^[1].

Основные определения

Область (англ. domain) — предметная область, для которой разрабатывается программное обеспечение.
Модель (англ. model) — описывает отдельные аспекты области и может быть использована для решения проблемы.
Язык описания — используется для единого стиля описания домена и модели.

Концепция

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

Схема архитектуры приложения представляет собой описание одной или нескольких моделей предметной области и их взаимосвязей между собой.

Ограниченные связи

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

Решение: Точно определить контекст, в котором используется модель. Определить границы использования данной модели и её характеристики.

Целостность

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

Решение: Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством тестирования. Это позволяет держаться всем разработчикам в одной большой концепции.

Взаимосвязь

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

Решение: На этапе проектирования точно обозначьте, что именно выполняет каждая модель и как она взаимосвязана с другими моделями. В конечном итоге у вас должна получиться карта взаимосвязей моделей.

Элементы DDD

При проектировании на основе предметно-ориентированного подхода используются следующие понятия:

Ограниченный контекст

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

клиентская база
система безопасности и защиты
резервное копирование
взаимодействие с платежными системами
ведение отчётности
администрирование
система уведомлений

Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают архитектурный стиль, который имеет красноречивое название «Большой ком грязи» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).^[2]

Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках.

Сущность

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

Объект-значение

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

Агрегат

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

Службы предметных областей

Иногда в предметной области есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой класс, не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести многослойную архитектуру, так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.^[3]

Взаимосвязь с подходами программирования

Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны объектно-ориентированного программирования. Это использование наследования, инкапсуляции, представления в виде методов и классов. Нужно помнить, что предметно-ориентированный подход может быть применен не только к ООП языкам, таким как Java, C# или C++, но так же и к функциональным — F#, Erlang. Особенно удобны языки, поддерживающие создание и использование собственных предметно-ориентированных языков, такие как Scala (см. также ЯОП).

См. также

Примечания

↑ Evans, Eric^[англ.]. Domain-Driven Design: Tackling Complexity in the Heart of Software (англ.). — Addison-Wesley, 2004. — ISBN 978-032-112521-7. Архивировано 7 мая 2021 года. в русском переводе Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем
↑ Brian Foote and Joseph Yoder, Big Ball of Mud Архивная копия от 27 мая 2012 на Wayback Machine, 1999, Urbana, IL 61801 USA
↑ Haywood, D., Domain-Driven Design using Naked Objects Архивная копия от 9 сентября 2017 на Wayback Machine, 2009, Pragmatic Programmers

Литература

Вон Вернон. Реализация методов предметно-ориентированного проектирования = Implementing Domain: Driven Design. — М.: «Вильямс», 2016. — 688 с. — ISBN 978-0-321-83457-7.

Эрик Эванс. Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем = Domain-Driven Design: Tackling Complexity in the Heart of Software. — М.: «Вильямс», 2011. — 448 с. — ISBN 978-5-8459-1597-9.
Нильссон Д. Применение DDD и шаблонов проектирования. Проблемно-ориентированное проектирование приложений с примерами на C# и .NET = Applying Domain-Driven Design and Patterns with Examples in C# and .NET. — М.: «Вильямс», 2008. — 549 с. — ISBN 978-5-8459-1296-1.
Evans E. Domain-Driven Design - Tackling Complexity in the Heart of Software. — Addison-Wesley, 2004. — 529 с. — ISBN 978-0-3211-2521-7.

Brian F., Joseph Y. Big Ball of Mud. — Urbana, IL 61801 USA, 1999. — 41 с.
Nick Tune, Scott Millett. Patterns, Principles And Practices Of Domain-driven Design. — 1-е изд. — "John Wiley & Sons", 2015. — 792 с. — ISBN 978-1118714706. — ISBN 1118714709.

Ссылки

Введение в проблемно-ориентированное проектирование Архивная копия от 18 мая 2011 на Wayback Machine (рус.)
Официальный сайт DDD Архивная копия от 30 апреля 2012 на Wayback Machine (англ.)
Принцип персональной ответственности Архивная копия от 22 мая 2012 на Wayback Machine (англ.)
Форум Domain-Driven Design (англ.)
Введение в проблемно-ориентированное проектирование Архивная копия от 14 апреля 2021 на Wayback Machine (англ.)
Qi4j фреймворк для DDD Архивная копия от 17 мая 2012 на Wayback Machine (англ.)
Plugger — фреймворк для DDD архитектуры в java приложениях (англ.)
JdonFramework — java-фреймворк для DDD (недоступная ссылка) (англ.)
Jon Jenkins из Clever Labs о важности проблемно-ориентированного подхода Архивная копия от 12 августа 2011 на Wayback Machine (англ.)
Eric Evans о DDD — Разработка модели Архивная копия от 21 июня 2013 на Wayback Machine (англ.)
Eric Evans о DDD — Стратегия проектирования Архивная копия от 9 мая 2012 на Wayback Machine (англ.)
Jimmy Nilsson о проблемно-ориентированном проектировании Архивная копия от 10 февраля 2012 на Wayback Machine (англ.)
Применение проблемно-ориентированного подхода в web разработке Архивная копия от 9 марта 2012 на Wayback Machine (англ.)
Интервью Dan Haywood’s на тему проблемно-ориентированного проектирования Архивная копия от 3 марта 2021 на Wayback Machine (англ.)
Брэд Эпплтон (Brad Appleton) о законе Деметры Архивная копия от 7 февраля 2012 на Wayback Machine (англ.)
Мартин Фаулер (Martin Fowler) описывает схему супертипа слоя Архивная копия от 6 июня 2012 на Wayback Machine (англ.)
Роберт С. Мартин о принципах S.O.L.I.D. Principles (Принципы) Архивная копия от 25 октября 2016 на Wayback Machine (англ.)

Видео

«Как съесть слона?», Немцов Александр Архивная копия от 26 декабря 2015 на Wayback Machine (рус.)
Eric Evans' on Defining DDD Архивная копия от 9 марта 2012 на Wayback Machine (англ.)
Eric Evans on DDD: Strategic Design Архивная копия от 9 мая 2012 на Wayback Machine (англ.)

[book.evans-1] Evans, Eric^[англ.]. Domain-Driven Design: Tackling Complexity in the Heart of Software (англ.). — Addison-Wesley, 2004. — ISBN 978-032-112521-7. Архивировано 7 мая 2021 года. в русском переводе Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем

[2] Brian Foote and Joseph Yoder, Big Ball of Mud Архивная копия от 27 мая 2012 на Wayback Machine, 1999, Urbana, IL 61801 USA

[1-3] Haywood, D., Domain-Driven Design using Naked Objects Архивная копия от 9 сентября 2017 на Wayback Machine, 2009, Pragmatic Programmers

[1]

[2]

[3]

@@ Строка 1: / Строка 1: @@
 {{Разработка программного обеспечения}}
-'''Предметно-ориентированное проектирование''' (реже проблемно-ориентированное, {{lang-en|domain-driven design}}, DDD) — это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями [[Предметная область|предметных областей]]. В эти модели входит [[бизнес-логика]], устанавливающая связь между реальными условиями области применения продукта и кодом.
+'''Предметно-ориентированное проектирование''' (реже проблемно-ориентированное, {{lang-en|domain-driven design}}, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями [[Предметная область|предметных областей]]. В эти модели входит [[бизнес-логика]], устанавливающая связь между реальными условиями области применения продукта и кодом.
 Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс [[Проектирование программного обеспечения|проектирования программного обеспечения]] в незнакомой предметной области.
@@ Строка 6: / Строка 6: @@
 Подход DDD особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать [[Программное обеспечение|ПО]], но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.
-Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»<ref name="book.evans">{{книга |заглавие=Domain-Driven Design: Tackling Complexity in the Heart of Software |год=2004 |издательство=[[Addison-Wesley]] |isbn=978-032-112521-7 |ссылка=http://www.domaindrivendesign.org/books/evans_2003 |ref=Evans |язык=en |автор={{Нп3|Eric Evans (technologist)|Evans, Eric|en|Eric Evans (technologist)}}}} в русском переводе ''Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем''</ref>.
+Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»<ref name="book.evans">{{книга |заглавие=Domain-Driven Design: Tackling Complexity in the Heart of Software |год=2004 |издательство=[[Addison-Wesley]] |isbn=978-032-112521-7 |ссылка=http://www.domaindrivendesign.org/books/evans_2003 |ref=Evans |язык=en |автор={{Нп3|Eric Evans (technologist)|Evans, Eric|en|Eric Evans (technologist)}} |archive-date=2021-05-07 |archive-url=https://web.archive.org/web/20210507021346/http://domaindrivendesign.org/books/evans_2003 }} в русском переводе ''Предметно-ориентированное проектирование (DDD): структуризация сложных программных систем''</ref>.
 == Основные определения ==
-* Область ({{lang-en|domain}}, ''[[домен]]'') — предметная область, к которой применяется разрабатываемое [[программное обеспечение]].
+* Область ({{lang-en|domain}}) — [[предметная область]], для которой разрабатывается [[программное обеспечение]].
 * Модель ({{lang-en|model}}) — описывает отдельные аспекты области и может быть использована для решения проблемы.
 * Язык описания — используется для единого стиля описания домена и модели.
@@ Строка 47: / Строка 47: @@
 * система уведомлений
-Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают [[Архитектура программного обеспечения|архитектурный стиль]], который имеет красноречивое название «[[Большой комок грязи|Большой ком грязи]]» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).<ref>Brian Foote and Joseph Yoder, [http://laputan.org/mud/ Big Ball of Mud], 1999, Urbana, IL 61801 USA</ref>
+Все перечисленные элементы должны быть включены в единую, работающую без перебоев систему. При проектировании система уведомлений и система безопасности выделяются как совершенно разные вещи. Системы, в которых при реализации не удаётся разделить и изолировать ограниченные контексты, часто приобретают [[Архитектура программного обеспечения|архитектурный стиль]], который имеет красноречивое название «[[Большой комок грязи|Большой ком грязи]]» в 1999 г. Брайан Фут (Brian Foot) и Йозеф Йодер (Joseph Yoder).<ref>Brian Foote and Joseph Yoder, [http://laputan.org/mud/ Big Ball of Mud] {{Wayback|url=http://laputan.org/mud/ |date=20120527154437 }}, 1999, Urbana, IL 61801 USA</ref>
 Сутью предметно-ориентированного проектирования является конкретное определение контекстов и ограничение моделирования в их рамках.
 === Сущность ===
-Проще всего [[Сущность (информатика)|сущности]] выражать в виде [[Существительные|существительных]]: люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более слабом коде можно найти массу служебных или управляющих [[Объектно-ориентированное программирование|классов]], проверяющих сущности снаружи.
+Проще всего [[Сущность (информатика)|сущности]] выражать в виде [[Существительные|существительных]]: люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более [[Зацепление (программирование)|слабо связанном]] коде можно найти массу служебных или управляющих [[Объектно-ориентированное программирование|классов]], проверяющих сущности снаружи.
 === Объект-значение ===
@@ Строка 58: / Строка 58: @@
 === Агрегат ===
-Агрегат — специальная сущность, к которой напрямую обращаются потребители. Использование агрегатов позволяет избегать чрезмерного соединения объектов между собой, составляющих модель. Это позволяет избежать путаницы и упростить структуру, потому что не позволяет создавать тесно связанные системы.
+Агрегат — специальная сущность, к которой напрямую обращаются потребители. Использование агрегатов позволяет избегать чрезмерного соединения объектов, составляющих модель, между собой. Это позволяет избежать путаницы и упростить структуру, потому что не позволяет создавать тесно связанные системы.
 === Службы предметных областей ===
-Иногда в [[Предметная область|предметной области]] есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой [[Объектно-ориентированное программирование|класс]], не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести [[Проектирование программного обеспечения|многослойную архитектуру]], так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.<ref name>Haywood, D., [http://www.pragprog.com/titles/dhnako/domain-driven-design-using-naked-objects Domain-Driven Design using Naked Objects], 2009, Pragmatic Programmers</ref>
+Иногда в [[Предметная область|предметной области]] есть операции или процессы, у которых нет обозначения или жизненного цикла. Службы области дают инструмент для моделирования этих концепций. Они характеризуются отсутствием состояния и высокой связностью, часто предоставляя один открытый метод и иногда перегрузку для действий над наборами. Если в поведение включено несколько зависимостей, и нет возможности найти подходящего места в сущности для размещения этого поведения, в этом случае используют службу. Хотя сам по себе термин «служба» в мире разработки перегружен различными значениями, но в данной тематике, это обозначает небольшой [[Объектно-ориентированное программирование|класс]], не представляющий конкретного человека, место или вещь в проектируемом приложении, но включающий в себя какие-то процессы. Использование служб позволяет ввести [[Проектирование программного обеспечения|многослойную архитектуру]], так же интегрировать несколько моделей, что вносит зависимость от инфраструктуры.<ref name>Haywood, D., [http://www.pragprog.com/titles/dhnako/domain-driven-design-using-naked-objects Domain-Driven Design using Naked Objects] {{Wayback|url=http://www.pragprog.com/titles/dhnako/domain-driven-design-using-naked-objects |date=20170909095851 }}, 2009, Pragmatic Programmers</ref>
 == Взаимосвязь с подходами программирования ==
-Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны [[Объектно-ориентированное программирование|объектно-ориентированного программирования]]. Это использование [[Наследование (программирование)|наследования]], [[Инкапсуляция (программирование)|инкапсуляции]], представления в виде методов и классов. Нужно помнить, что объектно-ориентированный подход может быть применен не только к ООП языкам, таким как [[Java]], [[C Sharp|C#]] или [[C++]], но так же и к функциональным — [[F Sharp|F#]], [[Erlang]]. Особенно удобны языки, поддерживающие создание и использование собственных [[Предметно-ориентированный язык|предметно-ориентированных языков]], такие как [[Scala (язык программирования)|Scala]] (см. также [[Языково-ориентированное программирование|ЯОП]]).
+Хотя по концепции предметно-ориентированное проектирование не должно быть ограничено какими-либо представлениями, но на практике используются сильные стороны [[Объектно-ориентированное программирование|объектно-ориентированного программирования]]. Это использование [[Наследование (программирование)|наследования]], [[Инкапсуляция (программирование)|инкапсуляции]], представления в виде методов и классов. Нужно помнить, что предметно-ориентированный подход может быть применен не только к ООП языкам, таким как [[Java]], [[C Sharp|C#]] или [[C++]], но так же и к функциональным — [[F Sharp|F#]], [[Erlang]]. Особенно удобны языки, поддерживающие создание и использование собственных [[Предметно-ориентированный язык|предметно-ориентированных языков]], такие как [[Scala (язык программирования)|Scala]] (см. также [[Языково-ориентированное программирование|ЯОП]]).
-== Примечания ==
-{{примечания}}
 == См. также ==
@@ Строка 76: / Строка 73: @@
 * [[Языково-ориентированное программирование]]
 * [[UML|Унифицированный язык моделирования (UML)]]
+== Примечания ==
+{{примечания}}
 == Литература ==
@@ Строка 111: / Строка 111: @@
 * {{книга
 |заглавие = Domain-Driven Design - Tackling Complexity in the Heart of Software
+|ссылка = https://archive.org/details/domaindrivendesi0000evan
 |автор = Evans E.
 |страниц = 529
@@ Строка 129: / Строка 130: @@
 == Ссылки ==
-* [http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx Введение в проблемно-ориентированное проектирование]{{ref-ru}}
+* [http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx Введение в проблемно-ориентированное проектирование] {{Wayback|url=http://msdn.microsoft.com/ru-ru/magazine/dd419654.aspx |date=20110518154638 }}{{ref-ru}}
-* [http://domaindrivendesign.org/ Официальный сайт DDD]{{ref-en}}
+* [http://domaindrivendesign.org/ Официальный сайт DDD] {{Wayback|url=http://domaindrivendesign.org/ |date=20120430125036 }}{{ref-en}}
-* [http://objectmentor.com/resources/articles/srp.pdf Принцип персональной ответственности]{{ref-en}}
+* [http://objectmentor.com/resources/articles/srp.pdf Принцип персональной ответственности] {{Wayback|url=http://objectmentor.com/resources/articles/srp.pdf |date=20120522102833 }}{{ref-en}}
 * [https://web.archive.org/web/20090615224147/http://tech.groups.yahoo.com/group/domaindrivendesign/ Форум Domain-Driven Design]{{ref-en}}
-* [http://www.methodsandtools.com/archive/archive.php?id=97 Введение в проблемно-ориентированное проектирование]{{ref-en}}
+* [http://www.methodsandtools.com/archive/archive.php?id=97 Введение в проблемно-ориентированное проектирование] {{Wayback|url=http://www.methodsandtools.com/archive/archive.php?id=97 |date=20210414043011 }}{{ref-en}}
-* [http://www.qi4j.org/ Qi4j фреймворк для DDD]{{ref-en}}
+* [http://www.qi4j.org/ Qi4j фреймворк для DDD] {{Wayback|url=http://www.qi4j.org/ |date=20120517062010 }}{{ref-en}}
 * [https://web.archive.org/web/20120320093629/http://www.plugger-project.org/ Plugger — фреймворк для DDD архитектуры в java приложениях]{{ref-en}}
 * [https://jdon.dev.java.net/ JdonFramework — java-фреймворк для DDD]{{Недоступная ссылка|date=Май 2019 |bot=InternetArchiveBot }}{{ref-en}}
-* [http://blog.cleverlabs.com/2010/11/domain-driven-design-that-works.html Jon Jenkins из Clever Labs о важности проблемно-ориентированного подхода]{{ref-en}}
+* [http://blog.cleverlabs.com/2010/11/domain-driven-design-that-works.html Jon Jenkins из Clever Labs о важности проблемно-ориентированного подхода] {{Wayback|url=http://blog.cleverlabs.com/2010/11/domain-driven-design-that-works.html |date=20110812142502 }}{{ref-en}}
-* [http://www.infoq.com/presentations/model-to-work-evans Eric Evans о DDD — Разработка модели]{{ref-en}}
+* [http://www.infoq.com/presentations/model-to-work-evans Eric Evans о DDD — Разработка модели] {{Wayback|url=http://www.infoq.com/presentations/model-to-work-evans |date=20130621185906 }}{{ref-en}}
-* [http://www.infoq.com/presentations/strategic-design-evans Eric Evans о DDD — Стратегия проектирования]{{ref-en}}
+* [http://www.infoq.com/presentations/strategic-design-evans Eric Evans о DDD — Стратегия проектирования] {{Wayback|url=http://www.infoq.com/presentations/strategic-design-evans |date=20120509201048 }}{{ref-en}}
-* [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nilsson о проблемно-ориентированном проектировании]{{ref-en}}
+* [http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design Jimmy Nilsson о проблемно-ориентированном проектировании] {{Wayback|url=http://www.infoq.com/interviews/jimmy-nilsson-domain-driven-design |date=20120210092233 }}{{ref-en}}
-* [http://skillsmatter.com/podcast/design-architecture/asynchronous-systems-architecture-for-the-web/wd-1569/ Применение проблемно-ориентированного подхода в web разработке]{{ref-en}}
+* [http://skillsmatter.com/podcast/design-architecture/asynchronous-systems-architecture-for-the-web/wd-1569/ Применение проблемно-ориентированного подхода в web разработке] {{Wayback|url=http://skillsmatter.com/podcast/design-architecture/asynchronous-systems-architecture-for-the-web/wd-1569/ |date=20120309051334 }}{{ref-en}}
-* [http://www.infoq.com/articles/haywood-ddd-no Интервью Dan Haywood’s на тему проблемно-ориентированного проектирования]{{ref-en}}
+* [http://www.infoq.com/articles/haywood-ddd-no Интервью Dan Haywood’s на тему проблемно-ориентированного проектирования] {{Wayback|url=http://www.infoq.com/articles/haywood-ddd-no |date=20210303155154 }}{{ref-en}}
-* [http://cmcrossroads.com/bradapp/docs/demeter-intro.html Брэд Эпплтон (Brad Appleton) о законе Деметры]{{ref-en}}
+* [http://cmcrossroads.com/bradapp/docs/demeter-intro.html Брэд Эпплтон (Brad Appleton) о законе Деметры] {{Wayback|url=http://cmcrossroads.com/bradapp/docs/demeter-intro.html |date=20120207225532 }}{{ref-en}}
-* [http://martinfowler.com/eaaCatalog/layerSupertype.html Мартин Фаулер (Martin Fowler) описывает схему супертипа слоя]{{ref-en}}
+* [http://martinfowler.com/eaaCatalog/layerSupertype.html Мартин Фаулер (Martin Fowler) описывает схему супертипа слоя] {{Wayback|url=http://martinfowler.com/eaaCatalog/layerSupertype.html |date=20120606064029 }}{{ref-en}}
-* [http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Роберт С. Мартин о принципах S.O.L.I.D. Principles (Принципы)]{{ref-en}}
+* [http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod Роберт С. Мартин о принципах S.O.L.I.D. Principles (Принципы)] {{Wayback|url=http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod |date=20161025223509 }}{{ref-en}}
-; Видео
+'''Видео'''
-* [https://www.youtube.com/watch?v=xqzUmJHeMhA&feature=player_embedded «Как съесть слона?», Немцов Александр]{{ref-ru}}
+* [https://www.youtube.com/watch?v=xqzUmJHeMhA&feature=player_embedded «Как съесть слона?», Немцов Александр] {{Wayback|url=https://www.youtube.com/watch?v=xqzUmJHeMhA&feature=player_embedded |date=20151226032453 }}{{ref-ru}}
-* [http://skillsmatter.com/podcast/design-architecture/keynoteddd-emerging-themes-2010/wd-1569 Eric Evans' on Defining DDD]{{ref-en}}
+* [http://skillsmatter.com/podcast/design-architecture/keynoteddd-emerging-themes-2010/wd-1569 Eric Evans' on Defining DDD] {{Wayback|url=http://skillsmatter.com/podcast/design-architecture/keynoteddd-emerging-themes-2010/wd-1569 |date=20120309051352 }}{{ref-en}}
-* [http://www.infoq.com/presentations/strategic-design-evans Eric Evans on DDD: Strategic Design]{{ref-en}}
+* [http://www.infoq.com/presentations/strategic-design-evans Eric Evans on DDD: Strategic Design] {{Wayback|url=http://www.infoq.com/presentations/strategic-design-evans |date=20120509201048 }}{{ref-en}}
 {{Software Engineering}}

Разработка программного обеспечения
Процесс	Стадии разработки Анализ требований Проектирование Программирование Тестирование Документирование
Высокоуровневые концепции	Архитектура ПО Парадигма Методология Процесс разработки Качество
Направления	Программирование (Аспектно-ориентированное Объектно-ориентированное Предметно-ориентированное)
Методологии разработки	Agile Cleanroom CASE UP RUP OpenUP RAD Scrum SAFe Модель Spotify MSF XP DSDM
Модели	Итеративная Каскадная Спиральная V-Model Dual Vee Model CMM CMMI Данных Function model^[англ.] IDEF Информационная Метамодель Object model^[англ.] View model^[англ.] UML
Известные деятели	Кент Бек Гради Буч Фред Брукс Уорд Каннингем Оле-Йохан Даль Том Демарко Эдсгер Дейкстра Дональд Кнут Алан Кэй Мартин Фаулер Энтони Хоар Ивар Якобсон Бертран Мейер Никлаус Вирт Эдвард Йордан Стив Макконнелл Джеймс Рамбо Барри Боэм Уоттс Хамфри^[англ.] Майкл А. Джексон^[англ.] Крэг Ларман Роберт Мартин Джеймс Мартин^[англ.] Дэвид Парнас^[англ.] Уинстон Ройс

Предметно-ориентированное проектирование: различия между версиями

Текущая версия от 23:24, 11 октября 2024

Содержание

Основные определения

Концепция

Ограниченные связи

Целостность

Взаимосвязь

Элементы DDD

Ограниченный контекст

Сущность

Объект-значение

Агрегат

Службы предметных областей

Взаимосвязь с подходами программирования

См. также

Примечания

Литература

Ссылки

Навигация

Предметно-ориентированное проектирование: различия между версиями

Текущая версия от 23:24, 11 октября 2024

Основные определения

Концепция

Ограниченные связи

Целостность

Взаимосвязь

Элементы DDD

Ограниченный контекст

Сущность

Объект-значение

Агрегат

Службы предметных областей

Взаимосвязь с подходами программирования

См. также

Примечания

Литература

Ссылки

Навигация

Поиск