Я все больше начинаю понимать Дизайн, ориентированный на предметную область, и немного запутался в том, как шаблон обнаженных объектов и луковая архитектура могут быть связаны друг с другом?
Совершенно ясно, как они соотносятся с DDD по отдельности, но можно ли также связать их друг с другом?
(Декларация о заинтересованности: я был автором архитектурного паттерна Naked Objects и управляю Naked Objects Framework — NOF.)
Я не утверждаю, что хорошо знаю архитектуру Onion, но на каком-то уровне идеи кажутся совместимыми с Naked Objects; на другом уровне это сравнение яблок с апельсинами.
Луковая архитектура — это набор принципов проектирования, которые можно применять при построении архитектуры с нуля с использованием различных технологий и шаблонов. Теоретически то же относится и к Naked Objects; на практике вы бы приняли шаблон «голые объекты» только путем создания своих систем с использованием фреймворка, который его реализовал — это слишком похоже на тяжелую работу, чтобы писать свои собственные. Платформа Naked Objects — самая крупная и чистая из таких сред, но не единственная.
Таким образом, значимое сравнение проводится не между луковичными принципами и принципами НЕТ, а между первыми и конкретной реализацией принципов НЕТ. Я, очевидно, буду использовать NOF в качестве примера.
NOF очень сильно реализует и применяет принципы, из которых основан Onion: очень сильное разделение задач. Модель предметной области почти полностью независима от инфраструктуры: единственная точка контакта — через один очень легкий интерфейс (IDomainObjectContainer), который определяет службу, реализация которой автоматически внедряется в любую сущность или службу предметной области, которая этого хочет. .
Даже в большей степени, чем в луковой архитектуре, ваш пользовательский интерфейс нулевой зависимости от модели предметной области, поскольку он является общим. (Если вы не начнете настраивать пользовательский интерфейс, в этом случае вы рискуете потерять преимущества шаблона NO).
Принципы Onion могут быть дополнительно применены внутри модели предметной области, гарантируя, например, что все доменные службы определяются и используются только интерфейсами. Я видел, как некоторые люди пытались сделать так, чтобы все взаимодействия между объектами предметной области проходили только через интерфейсы, но я никогда не видел, чтобы это работало в любом масштабе и не видело в этом мало пользы. Возможно, вы захотите прочитать о шаблоне «Кластер», который представляет собой шаблон для разбиения очень большой сложной модели предметной области на независимые кластеры со строгой иерархией зависимостей. Этот паттерн не зависит от NO, хотя на практике было бы мало смысла в его принятии, если бы вы также не имели преимущества NO.
И здесь я подхожу к своей главной мысли и к тому, что в первую очередь привело к определению паттерна НЕТ. Все это очень хорошо принимает строгие принципы разделения задач по всей архитектуре. Но до тех пор, пока вы не дойдете до точки, в которой и уровень сохраняемости, и уровень представления, будут на 100 % автоматически получены из объектной модели предметной области, вы в конечном итоге потеряете большую часть преимуществ такого разделения задач. , потому что любое изменение в модели предметной области влечет за собой изменения в других слоях, если не напрямую, то косвенно. Современные ORM проделали большую работу по сопоставлению модели предметной области с уровнем персистентности; Naked Objects сделали это для модели предметной области на уровне пользовательского интерфейса.
Короче говоря, если вы примете структуру, твердо приверженную принципам NO, вы получите заявленные преимущества Onion. Если ваше желание или потребность состоит в том, чтобы построить свою собственную архитектуру, и вы хотите принять принципы Onion, тогда это нормально, но тогда не стоит пытаться выяснить, как каким-то образом модифицировать любой из принципов NO для этой пользовательской архитектуры: это будет очень сложно, и вы, вероятно, не увидите никаких преимуществ.
