Товарищи, доброго времени суток. Вопрос, в первую очередь к Javистам.
Изучил DDD, и понял, что на первом месте здесь - модель предметной области в том виде, в каком её выявил анализ.
Но проясните такую вещь, можно ли 4-слойным дизайном имитировать DDD?

Т.е., построить классы таким образом, чтобы одному Entity, который является доменной сущностью, соответствовал сеансный компонент с методами. Методы сохранения состояния этих Entity перекрыть и размапить на таблицы, где это необходимо.

Пример, как я это вижу
У entity School есть список типа Class, они относятся один(школа) ко многим(классы).
По DDD это 2 связанных класса со свойствами и методами, сбоку прикручен механизм сохранения, т.е. сами классы на первом плане.
По аналогии проецируем эти принципы на 4-слойную. Получается School и Class - это два Entity, и делаем 2 сессионных бина: SchoolBean и ClassBean, но в SchoolBean добавляем метод getClasses(), который возвращает список классов. Но для работы с сущностью Class мы должны будем обратиться к бину ClassBean, у которого есть методы для работы с классом. Аналогичным образом можно выстроить любые бины с функциями, на вход которым нужно дать School, Class и т.д.
Это так или я заблуждаюсь?

Seva,

А при помощи DAO и TransferObjects можно абстрагироваться в моём примере?

А... кажется, понял...
По идее, слой логики сам "Не знает" ничего про методы работы с сохранением, кроме API репозитория?

JavaPhpLover-=*ShamaN*=-А... кажется, понял...
По идее, слой логики сам "Не знает" ничего про методы работы с сохранением, кроме API репозитория?

простите, можно уточнить - вы пытаетесь сделать что-то похожее на конструктор объектов 1С ?

Нет, я пытаюсь разобраться с вариантами построения логики...

SeVa-=*ShamaN*=-А... кажется, понял...
По идее, слой логики сам "Не знает" ничего про методы работы с сохранением, кроме API репозитория?

Правильно.Таким образом разгружаем домен, соблюдаем принцип единичной ответсвтенности, имеем возможность выбрать любой DAL

Хорошо, я внесу немного корректив в изначальную постановку:
1. Для сохранения объектов необходима абстракция (некий центральный DAO API), который знает, как хранить "Entity"
2. Соблюдение единичной ответственности, описанной в посте, возлагаем на организацию процесса разработки по принципу One Domain Object = One Entity + One SessionBean,

тогда логически и в голове получается тот же Domain Object, технически перевёрнутый в 2 класса.