добавил модели согласно ER диаграмме в чате. добавил сервисный уровень. на нем должна располагаться вся бизнес логика приложения, но в сервисах при этом не должно раскрываться внутреннее состояние сущностей.
на примере проще:
у Таска есть поле description. мы сделали поиск (используя другую функцию task_service'а). но нам нужно вернуть само описание задачи. и вместо того, чтобы обращаться в сервиса к переменной task, полю description (т.е. return task_found.description) мы вызываем метод модели get_description(),который внутри делает return self.description. => return task_found.get_description(). таким образом мы не раскрываем внутреннее устройство таски и если что-то изменится (от именования до логики), то нужно будет исправить лишь в методе get_description(), а не в каждом сервисе и каждом месте где задействоано это поле. это дает слабую связанность компонентов.
еще что хотелось бы отметить - хэндлеры должны быть максимально простыми и не содержать никакой работы с сущностями, для этого есть слой сервисов. хэндлер == тонкий контроллер, т.е. принимает запрос и тут же делегирует его сервису. затем возвращает его в нужной форме пользователю в чатик.
как опознать бизнес логику? - проще всего на мой взгляд спросить себя - что изменилось бы, если бы мы писали не бота, а приложение для айфона, но с теми же функциями и той же архитектурой. то, что изменлось бы (сппецифичная именно для айфона обработка сообщений, специфичная для джанги, специфика бота с его хэндлерами и командами) - это все тех детали. все что осатлось бы прежним (при создании таска нужно создать расписание(Schedule) и установить время создания, при создании проекта(категории) нужно определить ближайшее в ней событие и т.д.) - это и есть бизнес логика
P.S. не забудьте пересоздать базу скриптом, т.к констреинты, что идут из моделей навешиваются в момент создания и не меняются без пересоздания
добавил модели согласно ER диаграмме в чате. добавил сервисный уровень. на нем должна располагаться вся бизнес логика приложения, но в сервисах при этом не должно раскрываться внутреннее состояние сущностей.
на примере проще: у Таска есть поле description. мы сделали поиск (используя другую функцию task_service'а). но нам нужно вернуть само описание задачи. и вместо того, чтобы обращаться в сервиса к переменной task, полю description (т.е.
return task_found.description) мы вызываем метод моделиget_description(),который внутри делаетreturn self.description. =>return task_found.get_description(). таким образом мы не раскрываем внутреннее устройство таски и если что-то изменится (от именования до логики), то нужно будет исправить лишь в методеget_description(), а не в каждом сервисе и каждом месте где задействоано это поле. это дает слабую связанность компонентов.еще что хотелось бы отметить - хэндлеры должны быть максимально простыми и не содержать никакой работы с сущностями, для этого есть слой сервисов. хэндлер == тонкий контроллер, т.е. принимает запрос и тут же делегирует его сервису. затем возвращает его в нужной форме пользователю в чатик.
как опознать бизнес логику? - проще всего на мой взгляд спросить себя - что изменилось бы, если бы мы писали не бота, а приложение для айфона, но с теми же функциями и той же архитектурой. то, что изменлось бы (сппецифичная именно для айфона обработка сообщений, специфичная для джанги, специфика бота с его хэндлерами и командами) - это все тех детали. все что осатлось бы прежним (при создании таска нужно создать расписание(
Schedule) и установить время создания, при создании проекта(категории) нужно определить ближайшее в ней событие и т.д.) - это и есть бизнес логикаP.S. не забудьте пересоздать базу скриптом, т.к констреинты, что идут из моделей навешиваются в момент создания и не меняются без пересоздания