Я занимаюсь исследованием Domain Driven Design (далее DDD) уже более полугода.Я впервые познакомился с DDD, потому что знал, что такое режим перегрузки и что такое режим анемии, а потом я прикоснулся к DDD.Это был первый я познакомился с ДДД.Почему?Только сейчас я понял,что существует такое понятие как ДДД.После этого сомнения,которое сопровождало меня во взрослении,я продолжал усердно работать над ее решением во время своего роста,и наконец рассеял туман с помощью ДДД. Я сомневаюсь, во-первых, что мы приняли модель разработки, продолжительность которой мы не знаем, а именно Контроллер->Сервис->Дао,Сервисный уровень действует как класс бога, и вся логика забита внутри., правда ли, что эта модель вызывает бесконечное расширение сервисного слоя?Очевидно, что ответ не правильный, но на самом деле многие люди до сих пор равнодушны к этому, но как это улучшить? Когда я учился в колледже, я искал аутсорсинговые проекты для себя, чтобы сделать.Я однажды поставил себе риторику, насколько сложная система, пока она не требует обслуживания, добавления и модификации системы, я могу сделайте это, т.к. этот режим разработки действительно показывает CURD остро и ярко.Код старшего инженера реализует результат, и новичок может сделать то же самое (здесь результат, а не процесс, но фактический процесс может быть тем же, что и очень неудобно). Второй пункт фактически является продолжением первого пункта.С богатым опытом я начал разбираться в объектно-ориентированной и программной инженерии, потом пришла проблема,Где в этом традиционном режиме разработки объектно-ориентированный подход, где шаблон проектирования, который мы изучили, и где он применяется на практике?, На самом деле, мы часто продаем собачье мясо с головой овцы, голова овцы ориентирована на объект, мясо собаки ориентировано на процесс.
Далее я немного поведу вас в режим мышления DDD, сравню процессно-ориентированную разработку, к которой мы привыкли, и модельно-ориентированную разработку, поддерживаемую DDD, и постепенно перейду к объектно-ориентированному. Обратите внимание, что в этой статье рассказывается только о том, что такое DDD, а также о преимуществах и недостатках DDD, как это применять на практике, мы обсудим позже. DDD предлагает так называемыйМоделирование предметной области, на самом деле суть в единой ответственности класса в принципе объектно-ориентированной разработки, наш первый вопросКак быть с классом Бога Служения, который берет на себя слишком много обязанностей. Одно слово легко решается, то есть демонтаж.Автор когда-то пытался внедрить зависимость в класс службы со слишком многими другими классами в соответствии с руководством единственной ответственности класса.Таких может быть дюжина или двадцать.Читатели ,можете проверить на своем проекте.,это плохой код.Благо это на самом деле инкапсуляция функциональных точек,и это не может решить проблему не сделать класс Service раздутым.Он будет постепенно раздуваться,а суть в том всё-таки процессно-ориентированная разработка.Другая проблема, даже если такой подход и решает проблему раздутого класса Service, он не может решить очень критическую вещь, то есть код в нём не отражает бизнес. Что вы имеете в виду под не показывать бизнес? Например, чтобы активировать пользователей, как мы вообще развиваемся?
public class UserService{
public void updateAvailableById(long id,boolean available){
userDao.updateAvailableById(id,available);
}
}
Это очень типичный процессно-ориентированный код разработки, который можно увидеть повсюду в наших проектах, теряющий понятие объектов в объектно-ориентированном, и теперь, когда мы разрабатываем, мы скованы использованием баз данных. В первый момент, когда мы получаем спрос, на этапе анализа и проектирования мы часто анализируем и разрабатываем таблицу данных в качестве ядра, то есть сначала получаем имя и поля таблицы данных в соответствии с требованиями, а затем обучаем программисту научиться работать с этими таблицами данных с помощью операторов SQL.Затем, чтобы реализовать последовательную работу с таблицей данных, программист неизбежно будет писать код в процедурном стиле.С таблицей данных в качестве ядра для анализа и проектирования трудно избежать кода, который не превращается в процедурный код, потому что мы сосредоточены на работе с таблицей и связанным полем.. Вот так наз.Модель анемииТеперь UserDao представляет собой набор операторов SQL о пользовательских таблицах. Производительность в проекте заключается в написании набора операторов SQL. UserService используется в качестве записи сценария транзакции и смешивается с другими разными классами обслуживания. В течение всего этого процесса пользовательский объект ни разу не появился. Адвокационный подход, основанный на предметной области, заключается в следующем.
@Data
public class User{
private Long id;
private Boolean available;
public void activate(){
this.setAvailable(true);
}
}
//领域驱动服务
@Service
public class UserOperationService{
@Autowired
private UserRepository userRepository;
public void activate(User user){
user.activate();
userRepository.save(user);
}
}
Первый пунктПоведение, обогащенное классом (например, модели гиперемии), это объектно-ориентированная разработка, которая действительно пропагандируется. В центре внимания бизнес-системы находится бизнес-функция, а не то, как мы должны строить таблицы и писать операторы SQL для этой функции. Наше мышление всегда было похищено из-за использования базы данных.Теперь, как только я встал, я начал строить таблицы и писать код.Код был очень избыточным, и это был полностью процедурный образ мышления, что в конечном итоге сделало систему очень сложной в обслуживании. Бизнес-функция должна только понимать, что это функция активации, вместо того, чтобы устанавливать доступное в пользовательской таблице значение true, база данных — это просто инфраструктура, мы не должны обращать внимание и знать, как выглядит соответствующий оператор SQL, поэтому DDD подчеркивает Репозиторий вместо DAO, репозиторий переводится в ресурсы склада, что вам нужно, то и получаете, вам не нужно обращать внимание на фон, а DAO мы должны заботиться о том, как писать операторы SQL. Вы можете прочитать эту статью для более глубокого размышленияЕстественное сопротивление объектов и баз данных, Если вы все еще не понимаете это после прочтения, вы можете оставить свои сомнения в области комментариев.
Мы не должны реализовывать методы поведения, которые изначально принадлежали к модели предметной области, в службах.У объектов есть не только атрибуты, но и поведения для инкапсуляции данных и поведения и сопоставления их с реальными бизнес-объектами. Возвращаясь к тому, чему мы учили нас, когда впервые изучали объектно-ориентированный подход, все является классом, а не только одним классом бога.Нам нужно создать больше классов с соответствующей логикой, и каждый тип имеет четкое разделение обязанностей, чтобы логика рассредоточен на соответствующие объекты. Таким объектом является «модель перегрузки», и этот процесс также называется моделированием предметной области.В этом истинное значение объектно-ориентированного подхода!
Говоря об этом, у вас могут возникнуть некоторые сомнения по поводу приведенных выше примеров: 1. «Как такая простая функция может быть такой сложной с использованием DDD?», 2. «Вы имеете в виду использование гибернации ORM-фреймворка». 3. «Но разве все дело не в добавлении, удалении, проверке и изменении данных?»
Во-первых, почему DDD называет это способом разработки сложного программного обеспечения? Поскольку система достаточно сложна, эффект DDD может быть полностью продемонстрирован.Бизнес-логика стоит на самой высокой точке, так что любое изменение и расширение бизнес-логики может быть сделано для блокировки воды и почвы, что значительно снижает порог для коллег, которые новички в системе, чтобы начать работу. , и лучше избегать скрытых ошибок (у вас всегда будут бизнес-исключения, потому что вы случайно изменили строку кода). Для простых системных функций есть только простые добавления,удаления и ревизии.Вся бизнес логика на самом деле только простые добавления и запросы.Выделить модель предметной области невозможно.Если вы напрямую используете все теории DDD,то вы потеряете время и убить кур. Но вечного кода не бывает, а рефакторинг всегда сопровождается эволюцией всей системы, поэтому рекомендуется, даже если это простая система, лучше всего в начале настроить DDD, буду продолжать публиковать несколько статей позже, резюмирующих мое понимание Практики теории DDD.
По второму пункту рекомендуется прочитать эту статьюМысли об ORM в обмене практическим опытом проектирования, ориентированного на предметную область (DDD), или это предложение, если вы все еще не понимаете его после прочтения, оставьте сообщение в области сообщений. На самом деле, цель состоит в том, чтобы не допустить, чтобы моделирование данных, модель данных и технология баз данных похитили идею объектно-ориентированной разработки, что приводит к тому, что разработчики берут на себя инициативу в выводе дизайна таблицы, игнорируя исходный дизайн модели и формируя привычку мышления. Приятный дизайн." На самом деле Hibernate разработан под руководством теории JPA в DDD, что позволяет разработчикам больше сосредоточиться на реализации бизнес-логики и моделировании предметной области.
Другая проблема заключается в том, что многие люди ошибочно используют полную ORM-инфраструктуру, такую как спящий режим.Рекомендуется прочитать эту статью.Как сделать технический отбор для JPA или MyBatis
Третий момент заключается в том, что если у вас есть предварительное понимание DDD и вы хотите практиковать его, у вас действительно возникнет это сомнение.Сложность DDD заключается в том, что она требует изменения вашего мышления.Модель превращается в моделирование предметной области, и этот процесс обнажит недостаток вашей объектно-ориентированной функции передачи.Извините, вы давно не развивались с объектно-ориентированным мышлением. Алистер Кокберн предложил шестиугольную архитектуру, которая призвана решить проблемы, вызванные традиционной многоуровневой архитектурой.Он выступает за скрытие технических деталей и упор на бизнес-логику.Конечная цель состоит в том, чтобы реализовать возможность повторного использования бизнес-логики и организовать ее в многоразовую самозамкнутую бизнес-модель, то есть копирование без искажений.. Тщательно подумайте о режиме анемии, самым большим недостатком является то, что бизнес-логика не может быть повторно использована, и бизнес-логика не организована как многоразовая замкнутая бизнес-модель.