Ответ 1

Я думаю, что это определенно популярно в других местах, особенно в функциональных языках. Тем не менее, некоторые шаблоны, связанные с Большой Синей Книгой, не применимы в динамических языках, и такие рамки, как Rails, как правило, приводят людей к идеям ограниченного контекста.

Однако истинный толчок DDD, являющийся вездесущим языком, безусловно, распространен в динамических языках. Rubyists особенно приносит большую радость в создании доменных языков - подумайте о том, как функции огурца в конечном итоге выглядят, как DDD, так как он становится!

Имейте в виду, что DDD - это совсем не новая идея, она просто переупакована таким образом, чтобы получить хорошее понимание от С# и Java-парней. Те же самые идеи находятся в другом месте под разными баннерами.

Ответ 2

Этот вопрос беспокоит меня довольно долго, поэтому я решил собрать все ценные данные по этой теме. Наконец я в конечном итоге с этим GitHub репо.

Также есть пример кода:

1) На Джанго

2) на колбе

3) на рубине

И еще немного. Но точно не достаточно.

Ответ 3

Я предполагаю, что, поскольку DDD - это сложность моделирования, наиболее сложные модели, как правило, происходят от предприятия, которое, как правило, написано на Java, С# по крайней мере сейчас. Я думаю, что его изменение, но движение медленное

DDD на динамическом языке, вероятно, будет быстрее, меньше кода плиты котла

Здесь есть образец на Ruby здесь, tho - это DDD с CQRS

Ответ 4

Я думаю, что вполне возможно написать хорошие проекты DDD на динамических языках, но сложнее поддерживать, чем в статических. Зачем?

механическая обработка

Со статическими типизированными языками инструменты обычно сильнее. Вот почему некоторые люди используют TypeScript вместо простого JS, потому что это помогает вам масштабировать код, упрощая рефакторинг. Рефакторинг - это то, что присутствует каждый раз, когда вы поддерживаете DDD-код, потому что бизнес иногда меняется, и ваши знания о модели развиваются каждый день, и с этим знанием ваш код тоже должен развиваться. Большая часть моего опыта была с С#, и я создал много DDD-проектов с ним. Сейчас я работаю над проектом DDD, написанным на Ruby, и одна из вещей, по которым я больше всего скучаю, - это отсутствие сильной IDE. В Ruby или Python люди привыкли работать с текстовыми редакторами, а не с IDE. Мне трудно видеть, как люди пишут вещи, которые для меня должны писать некоторые IDE или текстовые редакторы (то есть отсутствие автозаполнения). Трудно увидеть людей, которые ищут полный путь к файлу в Vim, просто чтобы открыть его и посмотреть подробности о методе или классе - например, в VS Code или Visual Studio, одного нажатия на F12 должно быть достаточно для перехода к определению класса или метода, без неоднозначности файла. И я даже не говорил об опыте отладки, мне больно видеть, как люди пишут binding.pry (Для не-ruby разработчиков это немного похоже на ключевое слово "отладчик" в js), просто вместо этого отлаживаю его в терминале просто установить точку останова на линии. Список больше, чем этот, но я думаю, что этого достаточно, чтобы сделать вывод об "инструментах".

ООП выразительность

В некоторых динамических языках, таких как Python и Ruby, у вас нет всех функций ООП, таких как интерфейсы и абстрактные классы. Это иногда приводит к некоторым трудностям в создании выразительного и понятного кода.

Модульное тестирование

Вам нужно написать гораздо больше модульных тестов, чтобы заменить то, что компилятор может сделать для вас.

Динамическая печать

Вам нужно использовать утку, если вы хотите провести какую-то проверку типов. Никакой помощи от компилятора вы не получите.

Преимущества динамически типизированных языков

Сейф от Типа Ад

При выборе между динамическим ООП и статическим языком всегда есть компромисс. Одна из распространенных проблем в статически типизированных языках, таких как С# и Java, заключается в том, что иногда система типов может сделать код слишком невыразительным и слишком многословным. Некоторые разработчики стремятся попасть в ад типизации дженериков. Но не все статически типизированные языки имеют эту проблему (F # является одним из них - из-за строгого вывода типа).

тестирование

Отсутствие статических типов также помогает в некоторых случаях, когда, например, вы не хотите создавать интерфейс просто для внедрения в ваш класс и сделать его тестируемым. В этих случаях интерфейс не помогает в удобочитаемости, на самом деле он ухудшает читабельность, потому что вам нужно создать тупой файл (интерфейс), который не представляет ничего, кроме желания протестировать код. В Ruby вы можете сделать это несколькими способами, не создавая интерфейс, один из примеров:

class DispatchOrderService
  def initialize(overrides = {})
    @repository = overrides.fetch(:repository) do
      ::Infra::OrderRepository.new
    end

    @mail_service = overrides.fetch(:mail_service) do
      ::Infra::MailService.new
    end
  end

  def dispatch(order)
    order.dispatched
    repository.save(order)
    mail_service.notify_order_dispatched(order)
  end
end

Да, с этим подходом мы сломали чистую архитектуру, потому что класс знает конкретные "инфра" реализации. Но это проблема, которая может быть решена с помощью Dependency Injection (в Ruby эти фреймворки всегда ломали чистую архитектуру или слишком уродливы для того, чтобы кто-то захотел ее использовать, в наших проектах мы создавали собственный DI-контейнер, создавая зависимости вручную на запуск проекта).

Заключение

Итак, в заключение, я думаю, что можно написать хорошие "корпоративные" DDD-приложения на Ruby, даже если это сложнее, чем на статических языках. Мой текущий проект является одним из примеров этого (60 тыс. Строк кода и все еще поддерживается).

Также важно упомянуть @GeorgeMaueris. Вы можете столкнуться с проблемами при реализации DDD в средах, которые навязывают вам способ организации вашего кода. Здесь мы решили использовать Hanami вместо Rails из-за этого, но даже Hanami более "самоуверен", чем хотелось бы. Я действительно не рекомендую никому искать "рамки" для создания DDD. Дизайн/архитектура меняется от приложения к приложению, а также развивается. Когда вы выбираете "DDD" фреймворки, иногда вы сталкиваетесь с тем, что боретесь с ним (делая обходные пути или исправления обезьян).

Так что, может быть, вы можете спросить меня, почему мы выбираем рубин вообще. Основным моментом использования Ruby здесь было то, что почти 100% команды были составлены разработчиками Ruby, и мы не хотели дублировать трудности: изучение DDD + новый язык программирования. Больше стратегическое, чем чисто техническое решение. Компания (стартап), вероятно, не получится так далеко без нее.

РЕДАКТИРОВАТЬ 2018:

Мы отказываемся от Ruby и Python для наших проектов, основанных на аспектах DDD. Сейчас мы используем Kotlin и очень довольны. Основными бенефициарами были перечисленные здесь:

• Лучшая поддержка IDE с IntelliJ. Это значительно ускоряет рефакторинг, дает ошибки во время компиляции и требует меньше усилий для написания тестов для вещей, которые компилятор может сделать для нас.
• Хорошие и популярные фреймворки для Dependency Injection, ORM, функционального программирования
• Еще одно преимущество самого языка (нулевая безопасность, классы данных и т.д.)

Ответ 5

Большинство книг по методам проектирования/кодирования, таким как TDD и шаблоны проектирования, написаны на Java или С#, поскольку в настоящее время это самый низкий общий язык знаменателя и имеет самую широкую базу пользователей или, по крайней мере, самую большую базу людей, которые могут читать и понять язык. Это делается в основном по маркетинговым причинам, поэтому они обращаются к крупнейшим демографическим группам.

Это не означает, что методы не применимы или не используются на других языках. Из того, что я знаю о DDD, большинство принципов независимы от языка и AFAICR, в оригинальной книге DDD почти нет образцов кода (но прошло уже пару лет с тех пор, как я прочитал ее, поэтому я могу ошибаться).

Ответ 6

Python пока не слишком популярен на предприятиях по сравнению с Java (но я считаю, что ветер в этом направлении. Например, Django, созданный газетой). Большинство программистов, работающих с python, вероятно, либо в научных вычислениях, либо в веб-приложениях. Оба эти поля относятся к (компьютерным) наукам, а не к доменам, тогда как DDD наиболее применим в бизнес-доменах.

Поэтому я бы сказал, что это в основном вопрос наследия. С# и Java были нацелены на корпоративные приложения с самого начала.

Ответ 7

Если дизайн Driven Driven - это эффективно определенный шаблон дизайна, почему важно, какой язык вы используете? Совет по философии дизайна и тому подобное должен быть в значительной степени языковым агностиком. Они, как говорят, выше уровня, чем язык.