вторник, 2 декабря 2014 г.

Domain Design: Repository

Репозиторий

Обзор
Данная статья посвящена рассмотрению репозитория(Repository). В статье приведено небольшое математическое обоснование репозитория.

Что понимается под репозиторием? До недавнего времени многие разработчики пользовались таким понятием как DAO. На самом деле это уместное название способа работы с персистентными сущностями, так как никакие действия больше над сущностями не производились кроме как CRUD операций, при этом мы полагали что сущности, которые мы изменяем уже находятся в состоянии соответствии нашей бизнес модели. В итоге мы получали то, что некий сервис инкапсулировал в себе все свойства системы такие как валидания, расчеты, при все этом он еще был и внешним API системы. Но возникает вопрос: почему внешний сервис  должен все делать. Допустим что это его основные функции, но проблема возникает тогда когда начинает расти сложность бизнес логики и конечно часто меняющиеся требования... 
Репозиторий(repository) - это хранилище бизнес логики. Репозиторий обладает следующим свойством: данные которые в него попадают всегда должны соответствовать бизнес требованиям. Приведу небольшой математический аппарат для этого утверждения:

Пусть имеется некоторый репозиторий R. В данный репозиторий можно добавлять, удалять, изменять некоторую бизнес модель. В простом случае это некоторая сущность E(entity). Для того чтобы добавить в репозиторий некоторую сущность(E) необходимо проверить соответствует ли она нашей бизнес модели(требованиям). Пусть KFn(E)
- это соответствие n-бизнес требованию для сущности E в репозитории R. На самом деле  fn - это сложная бизнес функция проверки нашей сущности. В общем случае это F = F1 + F2+F3 + … + F где Fn - функция проверки на соответствие конкретным требованиям.
K= принимает два значения 1 или 0;
Емкость репозитория задается функцией:
то есть сущность попадает в репозиторий, если она соответствует бизнес требованиям. Если включаются новые бизнес требования, тогда можно специфицировать репозиторий для хранения новой бизнес логики или исключать обьекты которые уже не соответствуют вновь поступившим требованиям.

Продолжение следует...

Комментариев нет:

Отправить комментарий