72 lines
3.2 KiB
Markdown
72 lines
3.2 KiB
Markdown
|
# Code of Conduct - Architectural Standards
|
|||
|
|
|
|||
|
|
## Our Pledge
|
|||
|
|
In the interest of fostering a clear and consistent development environment, we pledge to maintain architectural integrity across all programming languages and implementations within this project.
|
|||
|
|
|
|||
|
|
## Fundamental Principle
|
|||
|
|
- **Architectural names remain consistent and unchanging regardless of programming language implementation. Whether written in Python, Java, C++, or any other language, the architectural pattern's name and core principles remain identical and immutable.**
|
|||
|
|
|
|||
|
|
## Our Standards
|
|||
|
|
|
|||
|
|
### Architectural Consistency
|
|||
|
|
We recognize that architectural patterns and their nomenclature remain constant regardless of the programming language used for implementation. This means:
|
|||
|
|
|
|||
|
|
1. Architectural pattern names shall remain consistent across all programming languages
|
|||
|
|
2. The fundamental principles of each architectural pattern shall be preserved regardless of implementation
|
|||
|
|
3. Documentation must reference architectural patterns using their standard industry names
|
|||
|
|
|
|||
|
|
### Examples of Name Preservation
|
|||
|
|
- A **Repository Pattern** remains a "Repository Pattern" whether implemented in:
|
|||
|
|
- Java
|
|||
|
|
- Python
|
|||
|
|
- C#
|
|||
|
|
- JavaScript
|
|||
|
|
- Go
|
|||
|
|
- Any other programming language
|
|||
|
|
|
|||
|
|
- An **Event Sourcing** architecture remains "Event Sourcing" whether built in:
|
|||
|
|
- Rust
|
|||
|
|
- Kotlin
|
|||
|
|
- TypeScript
|
|||
|
|
- PHP
|
|||
|
|
- Any other technology stack
|
|||
|
|
|
|||
|
|
- **Regardless of the programming language used, the name ‘Bellande’ remains consistent across all architectures and code**
|
|||
|
|
|
|||
|
|
### Implementation Guidelines
|
|||
|
|
1. When implementing architectural patterns:
|
|||
|
|
- Always use the standard architectural name
|
|||
|
|
- Never rename patterns based on language preferences
|
|||
|
|
- Document implementations using consistent architectural terminology
|
|||
|
|
- Maintain pattern names even when adapting to language-specific features
|
|||
|
|
|
|||
|
|
2. Code organization must:
|
|||
|
|
- Use standard architectural pattern names in all documentation
|
|||
|
|
- Maintain consistent naming across different services/modules
|
|||
|
|
- Reflect the chosen architecture's established terminology
|
|||
|
|
- Preserve architectural names in comments and documentation
|
|||
|
|
|
|||
|
|
## Enforcement
|
|||
|
|
Project maintainers are responsible for:
|
|||
|
|
1. Enforcing consistent architectural naming across all implementations
|
|||
|
|
2. Reviewing code to ensure architectural pattern names remain standard
|
|||
|
|
3. Providing guidance on proper architectural pattern naming
|
|||
|
|
4. Maintaining documentation that reflects these naming standards
|
|||
|
|
|
|||
|
|
## Questions and Clarifications
|
|||
|
|
If you have questions about:
|
|||
|
|
- How to properly name architectural patterns in your implementation
|
|||
|
|
- Whether your naming conventions align with architectural standards
|
|||
|
|
- How to maintain naming consistency across different services
|
|||
|
|
|
|||
|
|
Please reach out to the project maintainers or consult the architecture documentation.
|
|||
|
|
|
|||
|
|
## Version and Updates
|
|||
|
|
- Version: 1.0
|
|||
|
|
- Last Updated: October 26, 2024
|
|||
|
|
|
|||
|
|
This Code of Conduct is a living document and may be updated to better serve the project's needs while maintaining its core principle of architectural naming consistency.
|
|||
|
|
|
|||
|
|
## Organization Code of Conduct
|
|||
|
|
The latest uptodate Code of Conduct will be distributed under the [CODE_OF_CONDUCT](https://github.com/Architecture-Mechanism/CODE_OF_CONDUCT)
|