@proofit404 Здравствуйте! У меня вопрос о том как правильно использовать stories. Я пытаюсь понять как использовать его вместе с django rest framework. Например, где сериализовать модели? Внутри stories как один из шагов или я должен внутри сериализатора вызывать методы stories?
Был бы рад если бы вы хотя бы направили меня в правильном направлении.
Привет!
stories лучше всего использовать вместе с dependencies.
Рассмотрим как пример код из tutorials. У нас есть:
- Классическая форма Django. Как и обычно занимается она только изъятием данных из запроса и валидацией типов полей. Никаких проверок связанных полей!
- Django Form View, собранная из Injector. В нем через this нотацию достаются уже валидные данные и передаются в собранную стори.
- Обёртка для story, в которой прописана реализация методов, которые нужны самой story.
- Класс story, который принимает в виде аргументов данные из формы.
Для DRF всё тоже готово. Можно взять, например, ModelViewSet. У него есть методы create, update, destroy так же как у form view есть form_valid.
Если есть желание, можешь запилить api слой для tutorials. Готов менторить.
Надеюсь было полезно.
Если есть желание реализовать поддержку fastapi для dependencies - готов менторить.
Поддержка async def для stories есть в отдельном pr, но он ещё не смержен в мастер.
Можно посмотреть на https://github.com/dry-python/bookshelf
Тут основной принцип 1 в 1 как в чистой архитектуре Мартина.
В entities пишем бизнес правила (dataclasses без frameworkов), в usecases пишем бизнес сценарии (stories), реализацию в usecases прокидываем через dependencies.
FastAPI views выглядят одной строкой, которая обращается к инжектору и передаёт аргументы из запроса в usecase.
Тут основной принцип 1 в 1 как в чистой архитектуре Мартина.
В entities пишем бизнес правила (dataclasses без frameworkов), в usecases пишем бизнес сценарии (stories), реализацию в usecases прокидываем через dependencies.
FastAPI views выглядят одной строкой, которая обращается к инжектору и передаёт аргументы из запроса в usecase.
Отдельные шаги в story тестировать не надо. Надо тестировать поведение стори целеком.
Если есть необходимость тестирования отдельного шага - значит скорее всего в нём написана реализация завязанная на особенности системы, а не бизнес логика.
В таком случае детали реализации лучше вынести в отдельную функцию, протестировать её отдельно от story, и закинуть в инстанс стори уже через dependencies.
Например:
Если есть необходимость тестирования отдельного шага - значит скорее всего в нём написана реализация завязанная на особенности системы, а не бизнес логика.
В таком случае детали реализации лучше вынести в отдельную функцию, протестировать её отдельно от story, и закинуть в инстанс стори уже через dependencies.
Например:
Понимаю что лень писать, но это экономит время на чтение кода в дальнейшем. Можно, например, отделить keyword only arguments с помощью
def foo(a, b, *, c=1, d=2) синтаксиса.
@proofit404 в mr получил:
Знаю что костыль, но с другой стороны понимаю что лень все 20 аргументов отправлять в сервис руками:c есть ли какой-нибудь в arguments указывать не только название аргумента, но и описание в виде typing аннотации?(pydantic модель, это не по ddd, однако мы не стремимся получить идеальный ddd, лучше понятный по stories, но не слишком раздутый код)
accepted_data = {
key: value for key, value in ctx.__dict__[
'_Context__ns'
].items()
}Знаю что костыль, но с другой стороны понимаю что лень все 20 аргументов отправлять в сервис руками:c есть ли какой-нибудь в arguments указывать не только название аргумента, но и описание в виде typing аннотации?(pydantic модель, это не по ddd, однако мы не стремимся получить идеальный ddd, лучше понятный по stories, но не слишком раздутый код)
I hope it isn't across all over your codebase :)
Есть пара идей для плагина для mypy чтобы автоматизировать некоторые шаблонные куски кода. Но в целом должно работать.
вот маленький пример
нужно сделать много стори и соединить их ? или же можно как то переключать раут в стори на другой шаг ?
Лучше сделать из этого одну плоскую историю. Каждый шаг в порядке приоритетности проверки условий.
Если шаг проверяет своё условие и понимет, что ему ничего делать ненужно - он возвращает Success. Обработка переходит к следующему шагу.
Eсли шаг понимает что условие удовлетворено - вызвает необходимую обработку, возвращает Skip. Обработки данный истории прекращается.
Eсли обратобка условия это что-то сложное, лучше оформить саму обработку в отдельную историю в отдельном классе.
А вот уже шаг проверки условия преобразовать во вложенную историю из двух шагов. Первый проверяет условию, второй - история из отдельного класса.
Если шаг проверяет своё условие и понимет, что ему ничего делать ненужно - он возвращает Success. Обработка переходит к следующему шагу.
Eсли шаг понимает что условие удовлетворено - вызвает необходимую обработку, возвращает Skip. Обработки данный истории прекращается.
Eсли обратобка условия это что-то сложное, лучше оформить саму обработку в отдельную историю в отдельном классе.
А вот уже шаг проверки условия преобразовать во вложенную историю из двух шагов. Первый проверяет условию, второй - история из отдельного класса.
@proofit404 Добрый день! возможно ли (чтобы убрать лишний step вызова реализации) вместо:
>>> def find_price(self, ctx):
... ctx.price = self.impl.find_price(ctx.price_id)
... return Success()
>>> def __init__(self, impl):
... self.impl = implИспользовать:
>>> class Price:
...
... @story
... @arguments("category", "price_id")
... def find_price(I):
...
... I...
... I...
>>> class Subscription(MethodDefinitions):
...
... @story
... @arguments("category_id", "price_id", "profile_id")
... def buy(I):
...
... I.find_category
... I.impl.find_price
...
... def __init__(self, impl):
... self.impl = impl
Subscription(impl=Price()).buy
Можно передавать контекст целиком в метод реализации, и присваивать необходимые значения уже там внутри. Такой код будет так же тяжело понять как например пачку mixin, например в django views generic. Посмотреть в самом контексте кто и что туда положил можно через
print(ctx). Но в коде будет грязь.
@dataclass
class TokenUseCase:
@story
@arguments('user')
def obtain_token(I):
I.require_user_active
I.create_token
I.return_token
def require_user_active(self, ctx):
if ctx.user.is_active:
return Success()
return Failure()
def create_token(self, ctx):
ctx.token = self.create_user_token(ctx.user)
return Success()
def return_token(self, ctx):
return Result({'token': ctx.token})
# deps
create_user_token: Callable@proofit404 Добрый вечер! Например у меня есть TokenUseCase, который я хочу использовать напрямую для получения токена.
result = TokenUseCase(create_user_token=create_user_token).obtain_token.run(user=user)
token = result.value['token']Но также я хочу переиспользовать TokenUseCase.obtain_token как sub-story.
Но так сделать не получается, т.к. obtain_token возвращает Result и прекращает выполнение OtherUseCase.outer_story
obtain_token = TokenUseCase(create_user_token=create_user_token).obtain_token
OtherUseCase(find_token=obtain_token).outer_story.run()Как правильно организовать код в таком случае? Заранее спасибо!
Привет. Сразу скажу что красивого решения я пока не нашёл.
Я обычно такое поведение выношу в отдельную story, т.е. Result возвращаю на верхнем уровне вложенности.
@dataclass
class TokenUseCase:
@story
@arguments('user')
def obtain_user_token(I):
I.obtain_token
I.return_token
@story
@arguments('user')
def obtain_token(I):
I.require_user_active
I.create_tokenТаким образом мы можем вызвать obtain_user_token как самостоятельную сторю, а obtain_token как дочернюю сторю для какой-то более большой.
@proofit404 Добрый день! Еще вопрос, есть ли в планах сделать для stories какую-то обертку для io операций (чтобы например обернуть вызов к бд). Например как в библиотеке returns. Или в проектах вы используете returns? Но вроде не хочется couple stories и returns =) Буду благодарен за ответ.