Здравствуйте, alastochkin, Вы писали:

A> Если я выделяю DAL в отдельную сборку,
А для чего ты это делаешь?

A>Вопрос 1: Как обычно решается подобная проблема?
По разному...
1. Не выносят DAL в отдельную сборку. Сборка — это единица развертывания, а на практике развертывать DAL отдельно от BLL приходится редко. (Специально для педантов и зануд замечу, что это вовсе не означает отказ от разделения на DAL и BLL ).
2. Делают бизнес-сущности не зависимыми ни от чего, и вынеся их в отдельную сборку, можно использовать их и в BLL и в DAL сборках.
3. (Правильный =) ) Использовать одновременно первый и второй подход..

A>Недавно просматривал книгу Applying Domain-Driven Design and Patterns, и как я понял автор предлагает разделять классы Domain (состояние) и Business Logic (поведение). Мало того, говорит что классы Business Logic можно делать статическими, содержащими одни только методы, которые принимают экземпляр класса как аргумент, например static OrderManager.Save(Order order), а не Order.Save().
Умница, толковая должно быть книга... =)

A>Не могу понять такой подход. Вопрос 4: Проясните пожалуйста как подобную вещь с наследованием (см. ниже) сделать на Domain-Driven Design?:
Зачем Register(), OnRegister(), GetInstance и Kind нужны в Person?