D>Вот такие мысли. Поскольку я “замахнулся” на великого Фаулера, то мне интересно, что думаете вы.
1. Не принимать решения об архитектуре на основе абстрактных паттернов, принципов и личных предпочтений. Арохитектура не для того создаётся, чтобы вот тут затащить репозитарий а вот там — UOW.
2. Не возводить Фаулера в абсолют.
3. Изучать матчасть, уметь выделять типовые проблемы и знать, как их можно решить в рамках конкретного проекта.
4. Очень критично относиться к культу карго в методологиях.

Про паттерны очень хорошо

Автор: XopoSHiy
Дата: 14.04.10

написал Horishiy. Эх, перевели бы в своё время банду четырёх как "_приёмы_ проектирования" — насколько легче бы было

Если вернуться к исходному вопросу — надо смотреть на язык/фреймворк/инфраструктуру/сложившуюся архитектуру с одной стороны, и на бизнес-требования — с другой.

Десктоп или веб? Нужно ли разделять состояние, или каждая из частей системы работает со своей копией данных? Нужны ли транзакции в бизнес-коде? Нужна ли возможность получить состояние объекта до изменений? Нужна ли передача (с сохранением состояния) по сети? Есть ли уже готовое решение, подходящее под наши запросы? Если нет — во что обойдётся допилить/написать с 0?

Если ответить на эти вопросы — выбор будет очевиден и без Фаулера. Затраты на универсальный change-tracking и интеграцию его с DAL достаточно большие, готовых решений (включая разнообразные ORM) — как повезёт с выбранным языком/фреймворком, выбирайте

Если исходить из "просто и красиво" — нужно смотреть не на "а тут мы заиспользуем change tracker", а о том, чтобы большинство сценариев использования было интуитивно понятным. Не, ну серьёзно, если нужно поправить описание пользователю — зачем придумывать что-то кроме

  db.DoInTransaction(()=>
  {
    var user = db.Users.FindOrCreate("Alex")
    user.Description = "...";
  });