Если есть желание реализовать поддержку 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 =) Буду благодарен за ответ.
Я не очень понимаю как должен вести себя этот io wrapper внутри story. Какова его цель?
Что-то вроде такого:
```
# step
def load_image(self, ctx):
result = io_call(ctx.get_image_file(image_id=ctx.image_id))
if not is_successful(result):
return Failure('image_cannot_be_loaded')
ctx.image = unwrap(result)
return Success()
```С целью обозначить что будет выполнена io операция, которая которая может вызвать исключение, и чтобы можно было это исключение транслировать на зарегистрированную Failure.
Позожий механизм может быть и для
mappers нужен, поэтому не факт что враппер станет частью stories.
И в идеале наверное, чтобы был какой-то маппер, для для более гранулярного сопоставления исключений с failures.
А необработанные летели наверх или маппились с дефолтным failure. Имхо))
```
# step
def load_image(self, ctx):
wrapped = io_call(ctx.get_image_file(image_id=ctx.image_id))
if not is_successful(wrapped):
return Failure(wrapped.failure)
ctx.image = unwrap(wrapped)
return Success()
class RegisteredFailures(Enum):
image_cannot_be_loaded = auto()
image_not_found = auto()
permission_denied = auto()
def io_call(): -> FailureResult
pass
class ImageFailureResult(FailureResult):
@property
def failure(self):
failure = self._map(self._exception, RegisteredFailures.image_cannot_be_loaded)
return failure
```