> For the complete documentation index, see [llms.txt](https://lucid-architecture.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lucid-architecture.gitbook.io/docs/faq.md).

# FAQ

If you are still not sure of which way to go with a component, or just want to skim through some learnings based on our experience, here are some! If you wish to add to them please do so.

{% hint style="danger" %}
You are looking at the depricated version of the docs. See <https://docs.lucidarch.dev> for the latest documentation.
{% endhint %}

* **Should I skip controllers and call a feature from a router?**

  Yes, but! Keep it consistent. If you choose to skip controllers then skip it for all of your requests, not a few. Unless you have a clear definition of when to use a controller and where not to. As you can see already, it becomes confusing so to avoid the confusion choose an approach to adopt and stick to it.<br>
* **Should I call an operation from a router instead of a feature?**

  Maybe. Preferably not. This is because you will be indicating that this endpoint doesn't serve a feature and should have not been part of my application, but i need it for some reason. If your case is similar to something like health checks where `/health` would run `CheckAppHealthOperation` then yes because health checks are not features that your application provides. Otherwise, it will be confusing.<br>
* **Can a&#x20;*****Job*****&#x20;call another&#x20;*****Job***

  No. Please don't! This creates obscurity at all levels and defies one of the principles of Lucid - Clarity. Because when looking at a Feature or an Operation, you see a Job called `DoThisThingJob`\
  but when you run the code, you see that there is `ThisThing`, `ThatThing` and `AnotherThing` happening, then you shrug your shoulders in perplex and wonder where the other things are happening. Every single task must be in its own Job and the Feature/Job must provide the clarity and overview of all the steps required to be achieved. Otherwise, where do we stop nesting? and how do we know which Job calls which?<br>
* **Why do Jobs and Operations receive required parameters in Features instead of passing the input as received from the request as an array, or the `Request` class as input, which can even be injected in `handle` and we get rid of `__construct` altogether?**

  For several reasons:

  * **Clarity:**&#x20;
  * **Isolation**:
  * **Reusability:**