Модель предметной области — это визуальное представление концептуальных классов в предметной области или объектов реального мира. Модели предметной области также известны как концептуальные модели, объектные модели предметной области и аналитические объектные модели.
- "UML и применение шаблонов"
В нашей повседневной разработке мы часто спорим о некоторых функциональных точках: «Эта функция не должна быть изменена мной, ее должны изменить вы». наша собственная сторона. В отличие от традиционного архитектурного проектирования, проектирование на основе предметной области (DDD) может помочь вам в настоящее время добиться четкого разделения.
Что такое ДДД
Domain-driven design изначально был предложен Эриком Эвансом, но он уже много лет застрял в стадии концепции.Существует очень мало проектов и компаний, которые можно реально реализовать и внедрить.На самом деле Али активно продвигает концепцию DDD , что в основном может помочь нам решить проблему Традиционная монолитная централизованная архитектура трудно быстро реагировать на проблему бизнес-требований и дает рекомендации для сценариев, в которых преобладают промежуточные и микросервисы.
Что DDD предоставляет нам, так это методологию архитектурного проектирования, которая одновременно ориентирована на технологии и бизнес, и охватывает план проектирования с точки зрения бизнеса.
Роль ДДД
объединяющие мысли: Унифицировать познание бизнеса, продукта и разработки всех участников проекта, а не унификацию разработки и продукта и унификацию бизнеса и продукта, приводящую к различиям.
Четкое разделение труда: Модель предметной области должна быть четко определена для решения всех аспектов проблемы, и сформировано понимание командой этих проблем.
отражать изменения: Спрос постоянно меняется, поэтому наша модель тоже постоянно меняется. Модель предметной области действительно может отразить эти изменения.
разделение границы: Модель предметной области отделена от модели данных, и модель предметной области используется для определения того, какие требования и где должны быть реализованы, а также для сохранения ясности структуры.
Концепция ДДД
организация
Основной объект домена с уникальным флагом, который не меняется на протяжении всего жизненного цикла программного обеспечения. Эта концепция близка экземпляру модели, с которым мы обычно имеем дело с базой данных в нашей программной модели, с той лишь разницей, что эти сущности в DDD будут содержать бизнес-логику, связанную с сущностью, которая является носителем поведения операции.
объект значения
Привязанный к существованию объекта, объект идентифицируется атрибутом объекта и упаковывает некоторые связанные атрибуты объекта вместе, чтобы сформировать новый объект.
Возьмем каштан: например, сущность пользователя содержит имя пользователя, пароль, возраст, адрес, а адрес также содержит такие атрибуты, как провинции и города, и упаковка этих атрибутов провинций и городов в набор атрибутов является объектом-значением.
полимеризация
Сущности и объекты-значения представляют возможности отдельных лиц, а наша бизнес-логика часто сложна и не может быть завершена, полагаясь на отдельных лиц.В настоящее время несколько сущностей и объектов-значений должны работать вместе, и эта совместная организация представляет собой агрегацию. Агрегация — это основная единица модификации и сохранения данных.Консистентность транзакций должна быть гарантирована в рамках одного и того же агрегата.Поэтому при проектировании необходимо убедиться, что структура агрегата разделена до минимума, чтобы обеспечить эффективность и производительность.
Совокупный корень
Также известный как корневой объект, специальный объект, он является менеджером агрегата, представляющим запись агрегата, захватив корень агрегата, можно захватить весь агрегат.
Доменные службы
Некоторые операции предметной области представляют собой глаголы, которые не могут быть легко классифицированы как сущность или объект-значение. После того, как такое поведение будет идентифицировано из домена, его следует объявить сервисом, и его роль заключается только в обеспечении соответствующих функций для домена.
События домена
Запускается действиями пользователя в определенных полях, представляющих события, которые произошли в прошлом. Например, успешная перезарядка, события сбоя перезарядки.
Четыре режима
модель кровопотери
В модели есть только простой метод get set, который представляет собой простейшую инкапсуляцию сущности, а все остальные бизнес-поведения выполняются классом обслуживания.
@Data
@ToString
public class User {
private Long id;
private String username;
private String password;
private Integer status;
private Date createdAt;
private Date updatedAt;
private Integer isDeleted;
}
public class UserService{
public boolean isActive(User user){
return user.getStatus().equals(StatusEnum.ACTIVE.getCode());
}
}
Модель анемии
Поведение бизнес-домена агрегируется на основе модели потери крови, а изменения состояния объектов домена остаются на уровне памяти и не заботятся о сохранении данных.
@Data
@ToString
public class User {
private Long id;
private String username;
private String password;
private Integer status;
private Date createdAt;
private Date updatedAt;
private Integer isDeleted;
public boolean isActive(User user){
return user.getStatus().equals(StatusEnum.ACTIVE.getCode());
}
public void setUsername(String username){
return username.trim();
}
}
модель гиперемии
На основе модели анемии он отвечает за постоянство данных.
@Data
@ToString
public class User {
private Long id;
private String username;
private String password;
private Integer status;
private Date createdAt;
private Date updatedAt;
private Integer isDeleted;
private UserRepository userRepository;
public boolean isActive(User user){
return user.getStatus().equals(StatusEnum.ACTIVE.getCode());
}
public void setUsername(String username){
this.username = username.trim();
userRepository.update(user);
}
}
Модель отека крови
Сервис не требуется, вся бизнес-логика и хранилище данных размещены в одном классе.
Для DDD и кровопотеря, и отек неуместны, кровопотеря слишком легкая и не агрегируется, а отек только для новичков в написании такого кода. Итак, как выбрать модель гиперемии и модель анемии? Модель гиперемии опирается на интерфейс репозитория, тесно связана с хранением данных и рискует дестабилизировать программу.
метод моделирования
анализ варианта использования
Анализ вариантов использования — это самый простой и наиболее осуществимый способ моделирования предметной области. Его можно грубо разделить на несколько шагов: получение вариантов использования, сбор сущностей, добавление ассоциаций, добавление атрибутов и уточнение модели.
-
Пример использования: извлечение описания правила домена
-
Собирать сущности: находить сущности,
-
Добавить ассоциацию: две сущности связаны с глаголом
-
Добавить свойство: получить свойство объекта
-
Уточнение модели: необязательный шаг, отношения между моделями могут быть выражены обобщением и комбинацией UML, а поддомены могут быть разделены одновременно.
Метод четырехцветного моделирования
Метод четырехцветного моделирования является производным от "Java Modeling In Color With UML". Это метод анализа и проектирования моделей. Разделение всех моделей на четыре типа помогает модели быть четкой и прослеживаемой.
Проще говоря, четыре цвета фокусируются на чьем-то персонаже в определенном месте, делающем что-то с характером чего-то.
буря событий
Метод «шторма событий» похож на мозговой штурм: проще говоря, кто что сделал и когда на основе чего, что произвел и на что повлиял.
Слои архитектуры
В отличие от многоуровневой структуры традиционной архитектуры, показанной слева, общая многоуровневая структура DDD претерпит некоторые изменения.
Приложение: содержит регистрацию событий, бизнес-логику и т. д.
Домен: совокупность, сущность, объект значения
InfraStructure: инкапсуляция инфраструктуры, доступ к базе данных и т. д.
Суммировать
DDD — это полный набор методологий, который может помочь нам разумно спроектировать систему, в то же время хороший шаблон должен постоянно адаптироваться к изменениям, а DDD также может помочь нам быстрее и удобнее поддерживать развитие бизнеса.