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

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
Интерактивная навигация по истории
[непроверенная версия][отпатрулированная версия]
← Предыдущая правка
Содержимое удалено Содержимое добавлено
ВизуальныйВики-текст
Нет описания правки
м Исправление псевдозаголовков (см. Википедия:Доступность#Заголовки)
 
(не показано 28 промежуточных версий 19 участников)
Строка 1: Строка 1:
⚫
{{Разработка программного обеспечения}}
'''Предметно-ориентированное проектирование''' (реже проблемно-ориентированное, {{lang-en|Domain-driven design}}, DDD) — это набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями [[Предметная область|предметных областей]]. В эти модели входит [[бизнес-логика]], устанавливающая связь между реальными условиями области применения продукта и кодом.
'''Предметно-ориентированное проектирование''' (реже проблемно-ориентированное, {{lang-en|domain-driven design}}, DDD) — набор принципов и схем, направленных на создание оптимальных систем объектов. Сводится к созданию программных абстракций, которые называются моделями [[Предметная область|предметных областей]]. В эти модели входит [[бизнес-логика]], устанавливающая связь между реальными условиями области применения продукта и кодом.


Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс [[Проектирование программного обеспечения|проектирования программного обеспечения]] в незнакомой предметной области.
Предметно-ориентированное проектирование не является какой-либо конкретной технологией или методологией. DDD — это набор правил, которые позволяют принимать правильные проектные решения. Данный подход позволяет значительно ускорить процесс [[Проектирование программного обеспечения|проектирования программного обеспечения]] в незнакомой предметной области.
Строка 5: Строка 6:
Подход DDD особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать [[Программное обеспечение|ПО]], но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.
Подход DDD особо полезен в ситуациях, когда разработчик не является специалистом в области разрабатываемого продукта. К примеру: программист не может знать все области, в которых требуется создать [[Программное обеспечение|ПО]], но с помощью правильного представления структуры, посредством предметно-ориентированного подхода, может без труда спроектировать приложение, основываясь на ключевых моментах и знаниях рабочей области.


Данный термин был впервые введен Э. Эвансом в его книге с таким же названием «Domain-Driven Design»<ref name="book.evans">{{cite book |title=Domain-Driven Design: Tackling Complexity in the Heart of Software |last=Evans |first=Eric |authorlink=Eric Evans (technologist) |year=2004 |publisher=Addison-Wesley |isbn=978-032-112521-7|accessdate=August 12, 2012 |url=http://www.domaindrivendesign.org/books/evans_2003}} в русском переводе ''Предметно-ориентированное проектирование (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}}) — описывает отдельные аспекты области и может быть использована для решения проблемы.
* Модель ({{lang-en|model}}) — описывает отдельные аспекты области и может быть использована для решения проблемы.
* Язык описания — используется для единого стиля описания домена и модели.
* Язык описания — используется для единого стиля описания домена и модели.
Строка 23: Строка 24:


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


'''Решение:''' Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством [[Тестирование программного обеспечения|тестирования]]. Это позволяет держаться всем разработчикам в одной большой концепции.
'''Решение:''' Постоянное объединение кусков кода от различных разработчиков и проверка работоспособности посредством [[Тестирование программного обеспечения|тестирования]]. Это позволяет держаться всем разработчикам в одной большой концепции.
Строка 33: Строка 34:


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


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


Строка 46: Строка 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>


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


=== Сущность ===
=== Сущность ===
Проще всего сущности выражать в виде [[Существительные|существительных]]: люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более слабом коде можно найти массу служебных или управляющих [[Объектно-ориентированное программирование|классов]], проверяющих сущности снаружи.
Проще всего [[Сущность (информатика)|сущности]] выражать в виде [[Существительные|существительных]]: люди, места, товары и т. д. У сущностей есть и индивидуальность, и жизненный цикл. Во время проектирования думать о сущностях следует как о единицах поведения, нежели как о единицах данных. Чаще всего какие-то операции, которые вы пытаетесь добавить в модель, должна получить какая-то сущность, или при этом начинает создаваться или извлекаться новая сущность. В более [[Зацепление (программирование)|слабо связанном]] коде можно найти массу служебных или управляющих [[Объектно-ориентированное программирование|классов]], проверяющих сущности снаружи.


=== Объект-значение ===
=== Объект-значение ===
Строка 57: Строка 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]] (см. также [[Языково-ориентированное программирование|ЯОП]]).

⚫
== Примечания ==
⚫
{{примечания}}


== См. также ==
== См. также ==
Строка 75: Строка 73:
* [[Языково-ориентированное программирование]]
* [[Языково-ориентированное программирование]]
* [[UML|Унифицированный язык моделирования (UML)]]
* [[UML|Унифицированный язык моделирования (UML)]]

⚫
== Примечания ==
⚫
{{примечания}}


== Литература ==
== Литература ==
Строка 110: Строка 111:
* {{книга
* {{книга
|заглавие = Domain-Driven Design - Tackling Complexity in the Heart of Software
|заглавие = Domain-Driven Design - Tackling Complexity in the Heart of Software
|ссылка = https://archive.org/details/domaindrivendesi0000evan
|автор = Evans E.
|автор = Evans E.
|страниц = 529
|страниц = 529
Строка 128: Строка 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}}
* [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}}
* [http://www.plugger-project.org/ Plugger — фреймворк для DDD архитектуры в java приложениях]{{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]{{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}}
{{Software Engineering}}


{{rq|refless|topic=IT}}
{{rq|refless|topic=IT}}

⚫
[[Категория:Разработка программного обеспечения|П]]
[[Категория:Принципы программирования|П]]
[[Категория:Принципы программирования|П]]

Текущая версия от 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 (см. также ЯОП).

См. также

[править | править код]

Примечания

[править | править код]
  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
  3. ↑ 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.

Ссылки

[править | править код]

Видео

Источник — https://ru.wikipedia.org/ruwiki/w/index.php?title=Предметно-ориентированное_проектирование&oldid=140729272