InputType vs ArgsType + Architectural Discussion

I'm looking for a reference architecture in order to have all entities described consistently and came up with following. Something like this could be also helpful in the docs but yeah, first I wanted to discuss if this makes sense.

Example blog post entity:

1. `interface IPost` => what's is needed to **interact** with a `Post` instance (this could be anything such as all CRUD operations)
2. `class PostInput implements IPost` => what's is needed to **mutate** a `Post` instance
3. `class Post implements IPost` => what's needed to **persist** a `Post` instance

The GraphQL surface is always <= than above (so it's equal or a subset).

1 und 2 are more flexible than 3, means e.g. 1. and 2. can consist of optional properties only: When I create a new blog post, there's no need for any input, the `id`can come from the DB and initially the post content is empty. For 3, we need to have at least the `id` as primary key.

Now, I am wondering where `@ArgsType()` would fit in, I've two options:

**(A)** Like in the current docs: A dedicated `class PostInput` and dedicated classes `[specific use case]PostArgs`, e.g. `class GetTodaysPostsArgs`, one for every resolver:
```
@InputType()
class PostInput implements IPost

@ArgsType()
class GetTodaysPostsArgs implements IPost

...
```

**(B)** Or just one `class PostInput` both decorated `@InputType()` and `@ArgsType()`; since `class PostInput` is flexible, every use case should fit, it's DRY and should still give us some type safety, use always class validations (not so if I'd use `@Arg` from time to time), so something like...
```
@InputType()
@ArgsType()
class PostMutate implements IPost
```

Does this make sense?

Review the current documentation's @InputType and @ArgsType examples, then compare the proposed PostInput and resolver-specific argument classes with the GraphQL surface described here. Done means the architecture question has a decided direction and the resulting reference pattern is documented consistently.

Written by the indexing model from the issue text.