# 5-B.5 Create Developer Guidelines

Developer Guidelines should be a document that describes the rules how one specific project should be developed. Those rules will be unique for every project, but below you will find a few recommendations that should be included.

Above all, this should be a living document - continuously updated by the developers throughout the implementation phase, based on the insights and experience gained during development. Adherence to the guidelines will be a lot better, if they include the feedback and consensus of the development team.

For a starting point, the developer guidelines should include:

* Any rules derived from governance and compliance
* adherence to [5-B.2 Create Container Diagram](/implementation-playbook/1.0.1/implementation/design-architecture/5-b.2-create-container-diagram.md#modular-design)and [5-B.3 Create Component Diagram](/implementation-playbook/1.0.1/implementation/design-architecture/5-b.3-create-component-diagram.md#design-principles)
* Recommended patterns, like
  * [Architecture Best Practices & Patterns](/implementation-playbook/1.0.1/implementation/design-architecture/architecture-best-practices-and-patterns.md)
  * [GovStack Architecture Requirements](https://specs.govstack.global/architecture/6-cross-functional-requirements)
* Validation rules
  * What kind of validation should be performed on the inputs.
  * For example, a backend should **never trust the frontend** to provide valid inputs. Instead **validation must be performed (again) on the backend.** Otherwise there might be a threat vector for malicious actors.
* Error handling
  * how errors should be handled consistently across the application
  * what information is returned via the api
  * what information is to be logged
  * usage of error codes
* Logging Guidelines, provide guidelines on
  * what information to log
    * It is useful to have a unique identifier (uuid / guid) that groups log messages belonging together. An example would be a correlation id identifying an unique REST request.
    * In addition, it has proven valuable to define a "logging context". The logging context contains information that will always be logged with every message.
  * what log level to use when doing so
  * describe a consistent way of logging error scenarios
* Design Guidelines for Components, like
  * Separation of Business Code
    * Code that implements business rules should be separated from code that implements technical details (REST communication, Persistence Access)
    * This way the code stays more flexible and is easier to debug & maintain
  * Usage of Layers
    * Layered approaches are helpful to separate the business code from technical code
    * Example:\ <br>

      <figure><img src="/files/VzxnpQSmodFbNbHmUZvZ" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://specs.govstack.global/implementation-playbook/1.0.1/implementation/design-architecture/5-b.5-create-developer-guidelines.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.