Идея в том, чтобы заключить всю логику бизнес-логику связанную с объектом в одной сущности в данном случае BookBookService. Это и позволяет нам обеспечить внедрение зависимостей. Если по какой то причине этот класс поменяется, данную зависимость легко можно будет подменить в методе get_book_service.
1. В данном примере модели и играют роль DTO, в статье не приведены модели БД, предполагается, что они уже есть и созданы любым удобным способом. 2. Да они анемичные, потому что они выпоkняют роль DTO. 3. На диаграмме бизнес логи зависит не от БД, а от слоя repository, который выполняет взаимодействие с БД. 4. Бизнес логика не приведена в BookBookService, т.к. не хотелось высасывать ее из пальца.
Про ваш вывод вообще не очень понятно, что вы имеете в виду
Логика копипаста статьи в том, что на хабре ее не было, а материал для публикации кажется нам интересным.
По самому комментарию: думаем ваш вариант справдлив для микросервисной архитектуры, когда за работу с токеным отвечает отдельный сервис и приложению приходится ходить в этот сервис. В статье же описана джанга и монолит, так что для выписывания, валидации и других с действиям с токеном беку не нужно идти к другому сервису, он всю эту логику выполняет внутри себя.
Нет. Потому-что он есть только на Android.
Если его не исключать, то тогда его применение нужно обязательно описывать в Google Play. Без этого нельзя будет зарелизиться.
Идея в том, чтобы заключить всю логику бизнес-логику связанную с объектом в одной сущности в данном случае BookBookService. Это и позволяет нам обеспечить внедрение зависимостей. Если по какой то причине этот класс поменяется, данную зависимость легко можно будет подменить в методе get_book_service.
1. В данном примере модели и играют роль DTO, в статье не приведены модели БД, предполагается, что они уже есть и созданы любым удобным способом.
2. Да они анемичные, потому что они выпоkняют роль DTO.
3. На диаграмме бизнес логи зависит не от БД, а от слоя repository, который выполняет взаимодействие с БД.
4. Бизнес логика не приведена в BookBookService, т.к. не хотелось высасывать ее из пальца.
Про ваш вывод вообще не очень понятно, что вы имеете в виду
Спасибо, добавили)
Логика копипаста статьи в том, что на хабре ее не было, а материал для публикации кажется нам интересным.
По самому комментарию: думаем ваш вариант справдлив для микросервисной архитектуры, когда за работу с токеным отвечает отдельный сервис и приложению приходится ходить в этот сервис. В статье же описана джанга и монолит, так что для выписывания, валидации и других с действиям с токеном беку не нужно идти к другому сервису, он всю эту логику выполняет внутри себя.