Эта статья является тактической статьей DDD, в которой обсуждаются события предметной области, объекты предметной области, совокупные корни, сущности и объекты-значения. Это также конец серии DDD.
Эта часть является наиболее обсуждаемой в нашей команде, а также есть много менструальных сообщений, например о том, следует ли размещать работу библиотеки ресурсов в службе домена или в объекте домена.
Должен ли совокупный корень открываться внешнему миру или он должен быть преобразован в DTO. Мы обсуждали эти вопросы более полугода, и в конце концов все в основном пришли к единому мнению.
Эти вопросы не так важны, но они все вещи. На качество кода это сильно не повлияет. Практика DDD тесно связана с уровнем команды и сложностью бизнеса. Наш опыт может не обязательно относиться к вашей команде. Я поместил так много тактической главы в одну статью, и большая ее часть цитирует предыдущие обсуждения и резюме.
Причина в том, что в глубине души я не чувствую, что глава о практике тактики принесла много изменений в нашу команду. Глава о стратегии — это то, что я считаю более важным.
В серии DDD периодически появляется более десяти статей, в основном для обобщения проблем и решений, с которыми наша команда столкнулась в процессе посадки. Это полная замкнутая связь от обучения DDD до практики посадки. Надеюсь, она сможет вас вдохновить. Конечно, тот, кто больше всего выигрывает от этого процесса, должен быть я. Систематическое обдумывание проблем, обобщение проблем и проработка проблем очень полезны для улучшения личных мыслительных способностей. Друзья, вы также можете попробовать это.
моделирование
Появление DDD является отражением транзакционного программирования и таблично-ориентированного программирования баз данных.Ясно, что проектирование программного обеспечения является объектно-ориентированным проектированием, и необходимо учитывать наследование, полиморфизм и композицию между объектами.
Почему в реальном процессе кодирования становится процедурным программированием, почему у объекта есть только атрибуты и нет методов, то есть модель кровопотери.
Подробное введение в эти виды программирования см. на странице Мартина «Шаблоны архитектуры корпоративных приложений».
Поэтому я лично считаю, что DDD выполняет две функции: одна из них ориентирована на бизнес, помогая анализировать бизнес-модели и проводить бизнес-моделирование. Другой ориентирован на область решения, то есть на посадку кода.
То есть использование спецификации, которая может отражать отношения между объектами, то есть объектно-ориентированное программирование.
В настоящее время существуют в основном следующие категории исследований DDD.
На уровне бизнес-анализа, как абстрагироваться и разработать методологию на концептуальном уровне
Методология разделения услуг, иерархии кодов и определения ответственности
Пункт 3 в основном менее широко обсуждается. Я не думаю, что в будущем появятся какие-то замечательные DDD-фреймворки, которые станут популярными. DDD — это метод моделирования, ориентированный на разные сферы бизнеса,
У разных команд разные планы реализации, и нельзя полагаться на фреймворк, чтобы ограничить и унифицировать неоднородную вещь. Это похоже на то, что наш объектно-ориентированный дизайн абстрагирован от предметной области.
20+ шаблонов дизайна. Все эти шаблоны проектирования являются направляющей идеологией.Вы не можете придумать структуру, ограничивающую всех использовать определенный шаблон проектирования для расширения на основе этой структуры, чтобы добиться унификации кода или уменьшить
Цель сложности программирования.
Предыдущие статьи посвящены в основном более крупным аспектам, которые больше подходят для общего бизнес-анализа. Это первый пункт. Сегодня мы в основном обсуждаем второй пункт.
объектно-ориентированное программирование
Разделение кода и определение ответственности DDD по сути являются объектно-ориентированным программированием. Три основных элемента объектно-ориентированного программирования — это наследование, полиморфизм и композиция. Эти три являются результатом глубокой абстракции. Нет возможности направлять конкретное программирование.
Итак, у нас есть шаблоны проектирования.Предшественники обобщили 24 шаблона проектирования для проблемной области, так что, когда мы сталкиваемся с похожими проблемами, мы можем использовать соответствующие шаблоны проектирования для решения проблемы.
В основе этих шаблонов проектирования лежит наследование, полиморфизм и композиция.
Тогда есть шаблоны проектирования, зачем вам DDD? Почему DDD редко встречается в программном обеспечении с открытым исходным кодом?
Личное понимание DDD по-прежнему ориентировано наАрхитектура корпоративных приложенийЭто набор спецификаций, извлеченных из множества неопределенных предприятий и систем, поэтому он должен быть в высшей степени абстрактным. Большая часть программного обеспечения с открытым исходным кодом более определена в таких областях, как база данных и промежуточное программное обеспечение. Системные архитектуры для решения этих типов проблем часто бывают более сложными и масштабируемыми.
В интернете много инженерных архитектур DDD, я их тоже упоминал в предыдущих статьях, не буду повторяться здесь, посмотрите на старую конскую, думаю там очень четко показано разделение обязанностей.Мартин Фаулер.com/articles/m…
Мы фокусируемся на уровне домена.
Поле содержит 3 точки
Предоставляйте службы ресурсов (такие как базы данных, кэши и т. д.) для каждого уровня, реализовывайте развязку каждого уровня и уменьшайте влияние изменений внешних ресурсов на бизнес-логику.
Обратите внимание на публичный аккаунт [Abbot's Temple], как можно скорее получите обновление статьи и начните путь технической практики вместе с аббатом