Какова связь между DDD и «Луковой архитектурой»?

Question

Какова взаимосвязь между Домен-ориентированным дизайном (DDD) и " Луковая архитектура " Джеффри Палермо?

Answer 1

Если вы посмотрите на изображение, которое описывает архитектуру лука в предоставленной вами ссылке, DDD фокусируется на слое Доменная модель .

Лук - это архитектурный образец для системыв то время как DDD - это способ создания подмножества объектов в системе.Эти два могут существовать друг без друга, поэтому ни один из них не является подмножеством другого.Если бы вы использовали их вместе, то в целом часть, разработанная с использованием DDD, была бы подмножеством всей системы.

Чтобы использовать (вероятно, плохую) аналогию: лук - это шаблон для разработкидом, а DDD - это способ фрезерования древесины, которая является частью дома.

Answer 2

По-моему, они дополняют друг друга - но с очень разных точек зрения.

Архитектура Onion - это независимость Domain / BusinessLogic от «низших» вещей, таких как доступ к данным, пользовательский интерфейс, сервисы и т. Д.Архитектура Onion на самом деле не заботится о том, как вы создали домен, который у вас есть, - он непреклонен в защите его от внешних зависимостей.

Проектирование на основе доменов - это все, как вы моделируете свой домен и как вы называете свои объекты.Это означает, что каждый класс Домена должен иметь прямое отношение к тому, что он представляет в бизнес-домене, к которому он обращается (т. Е. В физическом / реальном мире).Таким образом, объект Customer должен называться Customer в коде - он должен иметь те же правила, что и Customer в реальном мире (или настолько близко, насколько это возможно).

Answer 3

Я думаю, что они отличаются друг от друга «как вы проектируете и какова ваша общая философия» в самой системе.

С луковой архитектурой весь мир вокруг вашего хранилища данных.Это означает, что вам не важно, как вы «выполняете работу», но вам важнее «я хочу, чтобы работа была выполнена».Очевидно, что лучшие практики (маленькие методы, хорошие имена переменных, может быть, некоторые шаблоны проектирования, такие как Sigleton и т. Д.) Все еще имеют значение в этой области видимости, но больше для самого кода, но не больше для всего обзора приложения.

С другой стороны, когда мы говорим о DDD, мы говорим о бизнесе, и когда мы принимаем решение об архитектуре, у нас всегда есть бизнес-модель, которую мы хотим решить.И когда я говорю «решение», я имею в виду общее количество решений, которые может принимать система (от имен переменных, классов и функций, до места размещения части кода и, в конце концов, как мы говорим о самой этой системе).Можно сказать, что DDD - это «программная абстракция» бизнес-модели).Но, конечно, мы не можем сделать так, чтобы у DDD не было бизнеса для решения проблемы. Мы не можем создать DDD для таких программ, как Shazam, но мы можем создать DDD для таких программ, как Facebook или Spotify.нельзя смешивать друг друга, но вместо этого это первое решение.