Вы чувствуете, что вы просто бизнес-CRUD Boy после многих лет разработки и думаете, что бизнес не имеет большого технического содержания. Не попадете ли вы в трясину бизнеса?Из-за различных сложных и переплетающихся бизнес-правил код начинает гнить и начинает выходить из-под контроля, проект становится сложно поддерживать, а итерация затруднительна. Если вы начнете осознавать эту проблему, то я настоятельно рекомендую вам начать изучать проектирование, управляемое предметной областью, подход к проектированию, ориентированный на моделирование предметной области.
Что такое ДДД?
DDD — это дизайн, управляемый доменом.В переводе на китайский язык это дизайн, управляемый доменом.Прежде всего, мы должны сначала понять, что здесь означает домен? Предположим, компания разрабатывает платформу электронной коммерции, и платформа электронной коммерции включает в себя основные виды деятельности, такие как запасы, заказы и товары. Эта основная бизнес-логика фактически представляет собой область платформ электронной коммерции. Популярное понимание состоит в том, что набор бизнес-знаний о системе представляет собой поле. Так же, как онлайн-образовательная платформа, она должна иметь систему бизнеса, включая регистрацию, онлайн-обучение, курсы и другой контент. Мы абстрагируем эти предприятия от модели предметной области, и эти модели предметной области выражают бизнес-требования, сформулированные менеджером по продукту. Мы неоднократно используем эти модели предметной области для обсуждения и общения с менеджером по продукту для окончательной доработки предварительной модели предметной области. Затем используйте предварительную модель предметной области для управления дизайном и разработкой кода.
В двух словах:
Бизнес-знания --> Модель предметной области --> Дизайн проекта и разработка кода
Основная бизнес-логика различных платформ электронной коммерции в основном схожа.Эта часть знаний предметной области может быть повторно использована.Разница заключается в разных языках программирования, интерфейсных средах управления и структурах баз данных, используемых разными компаниями. Преимущество использования доменно-ориентированного дизайна заключается в том, что проект использует модель предметной области в качестве ядра, в то время как интерфейсные среды управления, такие как Spring MVC и Struts или среды объектных баз данных Hibernate и Mybatis, относятся к основе периферийных технологий. Модель предметной области на самом деле не связана с этими базовыми технологиями, поэтому в предметной области с той же моделью мы можем легко заменить нашу инфраструктуру.
Значит, наша предыдущая разработка тоже поддерживалась этой бизнес-логикой? Тогда почему нашу традиционную модель разработки нельзя назвать дизайном, ориентированным на предметную область? Вспомните нашу предыдущую разработку кода, такую как функция реализации корзины покупок для размещения заказа. Мы используем поля таблицы заказов, чтобы собрать воедино запись в таблице заказов с полем продукта, полем суммы, полем пользователя и т. д. д., а затем напишите его в форму заказа. На самом деле мы разрабатываем под БД, ориентируемся на БД, а бизнес-логика разбросана по каждому сервису, используется процессно-ориентированный метод программирования вместо объектно-ориентированного, и органической бизнес-логики нет.
Дизайн, ориентированный на домен, отличается: он фокусируется на домене, взяв в качестве примера функцию заказа корзины покупок. В DDD бизнес-логика, связанная с корзиной покупок, инкапсулирована в объект ShoppingCart, а метод размещения заказа напрямую вызывается shoppingCart.takeOrder().Фокус кода переносится с записей в сгенерированной таблице заказов на сам объект корзины покупок, в то время как создание этой записи в конкретной базе данных не относится к нашей основной бизнес-логике.Это делегировано уровню инфраструктуры, а объекты взаимодействия с данными, такие как репозиторий или Dao, отвечают за сохранение сгенерированных изменений базы данных по инструкции выдаем на модель домена.
Код в проекте отражает бизнес-намерения экспертов предметной области посредством сотрудничества между различными моделями предметной области, что делает систему образующей самодействующее органическое целое. В предыдущем методе разработки, ориентированном на процесс, специалистам в предметной области или менеджерам по продуктам было трудно напрямую понять нашу бизнес-логику.Преимущество DDD заключается в том, что shoppingCart.takeOrder(), метод, похожий на народный язык, напрямую отражает бизнес-значение. И модель предметной области в нашем коде согласуется с моделью предметной области в устах экспертов предметной области. Даже мы можем напрямую смоделировать модель предметной области и начать писать код и тестировать для проверки бизнес-логики без технической поддержки инфраструктуры.
Сводная информация о модели предметной области
- Резюмировать основные понятия в этой области и установить отношения между понятиями;
- Модель предметной области поддерживает согласованность между данными в предметной области, то есть нашими бизнес-правилами;
Зачем нам ДДД
- Благодаря единому языку наши разработчики и эксперты в предметной области (менеджеры по продуктам) могут лучше общаться. Более точное представление нашего бизнеса, и эти бизнес-коды работают так, как думают эксперты в предметной области.
- Сосредоточьте бизнес-знания с помощью тактического проектирования и сконцентрируйте их в модели предметной области.
- В прошлом бизнес-коде нам всегда нужно было встраивать много комментариев, потому что способность процедурного кода к самообъяснению очень плоха, а лучший дизайн — это сам код. Знания в предметной области представлены через сам код.
- Деконструируйте и упрощайте сложные бизнес-системы с помощью стратегического проектирования.
Тактический дизайн и стратегический дизайн являются локальными и общими рекомендациями DDD по дизайну.
Анемия и амнезия
В традиционном режиме разработки мы часто используем JavaBean, который имеет только поля, сопоставленные с базой данных, и не имеет бизнес-поведения. Заполнив этот JavaBean и написав бизнес-логику вне объекта, например вычислив окончательную сумму заказа, заполнив ее в JavaBean и затем передав ее в структуру сопоставления базы данных для сохранения.
На самом деле это то, что Эванс называет анемией, потому что данные и бизнес-поведение изолированы, образуя неорганическую композицию кода. На самом деле это не объектно-ориентированный метод кодирования, когда мы видим объект Order, мы просто не знаем, что он содержит бизнес-логику для расчета конечной суммы, что на самом деле является так называемой амнезией, вызванной анемией. Данные и поведение не тесно связаны.
public static void buyProduct(Long orderId, Double price, Long productId, Float discount) {
Order order = new Order();
order.setOrderId(orderId);
order.setProductId(productId);
order.setDiscount(discount);
order.setPrice(price);
// 计算最终付款金额
if(discount == 0) {
throw new RuntimeException("折扣不可为0！");
}
Double paid = price * discount;
order.setPaid(paid);
OrderDao.save(order);
}
Лучше сделать так, чтобы они образовывали органичную композицию кода, интегрируя данные и бизнес-поведение в один объект. Один из принципов GRASP Object Responsibility заключается в том, что если объект обладает свойствами, требуемыми для метода, то лучше поместить метод в объект, а не где-либо еще.
public static void buyProduct_(Long orderId, Double price, Long productId, Float discount) {
Order order = new Order(orderId, price, productId, discount);
order.calculatePaid();
OrderDao.save(order);
}
Приведенный выше пример больше соответствует нашему описанию бизнеса, но недостаточно подчеркнуть только инкапсуляцию бизнес-логики в объекты данных, нам также необходимо выразить бизнес через взаимодействие между этими объектами. Очевидным примером является случай трансферов.
public static void main(String[] args) {
Account a = new Account(5);
Account b = new Account(5);
double transferMoney = 4;
if (a.getMoney() < transferMoney) {
throw new RuntimeException("余额不足！");
}
a.setMoney(a.getMoney() - transferMoney);
b.setMoney(b.getMoney() + transferMoney);
}
Для лучшего подхода мы должны извлечь уроки из объектно-ориентированного моделирования и инкапсулировать знания предметной области в модель учетной записи.
public void transfer(Account another, double transferMoney) {
if (money < transferMoney) {
throw new RuntimeException("余额不足！");
}
money = money - transferMoney;
another.setMoney(another.getMoney() + transferMoney);
}
Перевод со счета А на счет Б.
public static void main(String[] args) {
Account a = new Account(5);
Account b = new Account(5);
double transferMoney = 4;
a.transfer(b, transferMoney);
}
Благодаря сотрудничеству между моделями предметной области представленный код похож на местный. Есть объект-предикат субъекта. Субъектом является учетная запись A, предикатом является метод transfer(), а объектом является учетная запись B. Таким образом, самоочевидность кода также очень сильна. Даже если менеджер по продукту не знает языка программирования, видя наш код, он может понять бизнес-цель.
Применимые сценарии DDD
Итак, какие сценарии подходят для DDD?
В обозримом будущем бизнес-сложность проекта будет становиться все выше и выше, поэтому очень удобно использовать метод проектирования DDD. И если все проекты - это очень простые добавления, удаления и ревизии с небольшими знаниями в области бизнеса, то я действительно не могу подняться до D, потому что идея DDD состоит в том, чтобы выражать знания предметной области через модели, а само знание предметной области очень отсутствует. Если да, то нет способа выразить это.
Как сделать ДДД
Мы можем использовать один и тот же общий язык с экспертами в предметной области (менеджерами по продуктам), чтобы абстрагировать модель предметной области с помощью общего языка и разрабатывать код в соответствии с этими моделями предметной области, чтобы бизнес-сфера могла лучше отражаться в коде. Нам нужно изменить наши прежние привычки мышления, думая меньше с технического уровня, а больше с уровня бизнеса. Насколько я понимаю, DDD — это набор методологий объектно-ориентированного программирования, основанных на предметной области в качестве ядра. Он в основном реализует DDD в двух вариантах. Одним из них является тактический дизайн, который вы можете понимать как дизайн в рамках одного микросервиса. Одним из них является стратегическое проектирование, которое вы можете понять как взаимодействие нескольких микросервисов.
тактический дизайн
Тактический дизайн ориентирован на локальный дизайн, в основном включающий следующие концепции:
- Сущность: имеет уникальный идентификатор и жизненный цикл, который можно понимать как запись, которая может соответствовать базе данных через сущность.
- Объект-значение: свойство, используемое для описания сущности.
- Агрегация: содержит объекты сущностей и значений и поддерживает согласованность транзакций.
- Репозиторий: используется для получения или сохранения агрегатов.
- Доменные службы: поместите некоторую бизнес-логику, которая не вписывается в агрегаты.
Давайте кратко объясним, как эти концепции работают в одном ограниченном контексте (то есть в одном микросервисе). Агрегаты состоят из сущностей и объектов-значений, которые поддерживают согласованность транзакций. Агрегаты сохраняются и ищутся или получаются репозиторием. И когда некоторые бизнес-правила не подходят для сущностей или объектов значений, мы можем использовать доменные службы.
стратегическое моделирование
Стратегический дизайн фокусируется на разработке того, как различные части целого работают вместе, в основном включая следующие концепции:
- Ограниченный контекст: класс контекста, в котором работает модель предметной области. Например, товарный модуль в электронной коммерции является ограниченным контекстом.
- Карта контекста: как взаимодействуют разные классы моделей предметной области. Например, как модуль товаров взаимодействует с модулем инвентаризации на платформе электронной коммерции.
Ограниченный контекст — это концептуальная граница, в которой работает модель предметной области, то есть ограниченный контекст соответствует разрабатываемому нами микросервису. Что касается того, как общаться в разных контекстах, концепция контекстной карты используется для управления развитием.
Существует много дискуссий о DDD, и у всех разные мнения, что является одной из причин, почему DDD трудно завоевать. Но идея DDD по-прежнему очень достойна упоминания. Для изучения DDD настоятельно рекомендуется прочитать оригинальные DDD и IDDD.
Ниже приводится книга в формате PDF о DDD и IDDD, загруженная автором, и я надеюсь, что она поможет друзьям, которые хотят изучить DDD.
«Дизайн, ориентированный на предметную область: преодоление сложности в основе программного обеспечения»Код извлечения: 6290
Внедрение дизайна, управляемого доменомКод извлечения: xl3t