test_task,

очень все не однозначно с самим заданием. вы можете описать архитектуру, идею, которую вы заложили в реализацию? как оно работает?

у нас типа финансовая система, поэтому я как ведущий программист подумал бы о следующих вещах:
1. вход пользователя - в задании нет никаких требований по безопасности, возможно для упрощения, но я как минимум описал бы свои мысли по этому поводу - например шифрование пароля, двухфакторная аутентификация
2. отложенность транзакций - вы замечали, что деньги на межбанковские переводы у вас с банковского счета не списываются в выходные дни? пишет - заблокировано средств столько-то. в задании конечно есть ограничение - что это какая-то внутренняя система, но я бы подумал о расширении - например подключении внешних платежных систем и банковский счетов
3. производительность - как вы собираетесь распараллеливать обработку транзакций? возможно нужна очередь в базе данных или MQ
4. логирование - пользователи очень очень преочень беспокоятся за свои деньги, даже за одну копейку - как вы собираетесь обеспечить нужный уровень логирования ошибок, событий, чтобы в будущем разобраться почему деньги исчезли или ушли не туда?
5. отказоустойчивость - как вы собираетесь решать эту проблему на клиенте, на сервере? да хотя бы потеря сети? или превышение таймаута запроса
6. устойчивость к хакерским атакам - например насколько легко подделать данные, отправить их на сервер, чтобы списалось больше денег или ушло не тому человеку?
7. в задании было что-то про уведомления пользователей чуть ли не на каждый чих - опять же это отдельная тема как по расширению (куда уведомлять? на мыло, на мобильник, пуш-уведомление?), так и по производительности (пользователей много, уведомлений еще больше, как минимум раза в два), а так же по способу (опрашиваем сервер или подписываемся на уведомления и сервер шлет на клиенты)
8. требование RESTfull - в текущей реализации это не совсем RESTfull, но я не уверен - понимают ли постановщики тестового задания этот термин в полной мере. вот хорошая статья https://habrahabr.ru/post/319984
9. я не знаком с мобильной разработкой, но слышал, что там есть особенности по аутентификации и авторизации

вот только после того, как вы обдумаете и распишите эти вопросы (кстати это будет и некая документация) - сможете приступить к технической реализации - это выбор технологий и все те самые паттерны, солиды, сервисы, репозитории и т.п.

и это уже будет совсем другая история

а вот тут можете почитать про эволюцию кода от репозиториев до CQRS http://blog.byndyu.ru/2014/07/command-and-query-responsibility.html и это было написано три года назад

skyANAА завтра понадобится три метода вызывать в рамках одной транзакции, что будете делать?

test_task
вот, кстати, раз уж используете NHibernate - если при этом использовать Castle Windsor, то там есть уже готовая NHibernateFacility и AutoTx - вешаешь атрибут транзакции на публичный метод класса - и вперед, поддерживает вложенные транзакции и вложенные методы

AntonariyhVostt Репозиторий объектов типа А должен работать только с объектами типа А, а не А, АDto, АHZChto...То есть если, например, репозиторий А должен произвести операцию не только с объектом А, но и со связанными с ним объектами B и С, то эти манипуляции все равно нужно выносить в соответсвующие репозитории? Даже если эти манипуляции в отрыве от операции А вообще не применяются?
а что за манипуляции вы имеете ввиду?
например у вас DDD, есть Entity, у нее Value Object, то репозиторий должен работать только с Entity, будет IRepository<TEntity>
и вот там внутри он будет раскладывать это допустим по двум таблицам в БД

а насчет классов DDD и ORM - я как-то видел в одном проекте решение - классы DDD с логикой очень хитрыми и сложными маппингами гибернейта раскладывались в таблицы, без промежуточных, приближенных к таблицам классов ORM