<commit_before>---
bodyclass: docs
headline: Naming Conventions
layout: docs
sidenav: doc-side-guides-nav.html
title: Naming Conventions
type: markdown
---

<p>This document covers the naming conventions used in the framework and how these conventions are 
used by the code generation.</p>

## Proto files

Proto files are named using the `snake_case`, as defined by Protobuf. There are several special
kinds of files.

### Identifiers   

Commands and events reference model entities via their identifiers. 
Having typed identifiers makes a model type safe.
Although the framework also supports `String`, `Integer`, and `Long` as valid ID types, 
we strongly recommend defining custom ID types like `CustomerId`, `OrderId`, `ShipmentId`, etc. 
You can find similar cases in the framework API which has `EventId`, `CommandId`, `UserId`, 
`TenantId`, etc. 

We found it convenient to define ID types in one file called `identifiers.proto`. 
A typical project is likely to have more than one Bounded Context, so you
are going to have several `identifiers.proto` each residing under the directory with proto
files defining the data model of the corresponding Bounded Context.   

### Command definitions

Commands are defined in a file which names end with `commands.proto`. 
It can be simply `commands.proto`, but usually there are many commands that are handled by 
different aggregates. So, it's convenient to name such files after the type of the target
aggregate: 

 * `blog_commands.proto` 
 * `order_commands.proto` 
 * `customer_commands.proto`

### Event definitions

Similarly to commands, events are defined in files which names has the `events.proto` suffix:

 * `blog_events.proto` 
 * `order_events.proto`
 * `customer_events.proto`.

### Rejection definitions

`Rejection` is a special — so to say, “negative” — kind of events supported by the framework. 
A rejection is thrown if a command cannot be handled. Think exceptions, but of non-technical flavor.

Similarly to events, rejections are defined in files ending with `rejections.proto`:

  * `blog_rejections.proto` <commit_msg>Improve language on naming command files<commit_after>---
bodyclass: docs
headline: Naming Conventions
layout: docs
sidenav: doc-side-guides-nav.html
title: Naming Conventions
type: markdown
---

<p>This document covers the naming conventions used in the framework and how these conventions are 
used by the code generation.</p>

## Proto files

Proto files are named using the `snake_case`, as defined by Protobuf. There are several special
kinds of files.

### Identifiers   

Commands and events reference model entities via their identifiers. 
Having typed identifiers makes a model type safe.
Although the framework also supports `String`, `Integer`, and `Long` as valid ID types, 
we strongly recommend defining custom ID types like `CustomerId`, `OrderId`, `ShipmentId`, etc. 
You can find similar cases in the framework API which has `EventId`, `CommandId`, `UserId`, 
`TenantId`, etc. 

We found it convenient to define ID types in one file called `identifiers.proto`. 
A typical project is likely to have more than one Bounded Context, so you
are going to have several `identifiers.proto` each residing under the directory with proto
files defining the data model of the corresponding Bounded Context.   

### Command definitions

Commands are defined in a file which names end with `commands.proto`. 
It can be simply `commands.proto`, but usually commands are handled by different entities. 
So, it's convenient to name such a file after the type of the target entity, 
for instance, an aggregate: 

 * `blog_commands.proto` 
 * `order_commands.proto` 
 * `customer_commands.proto`

### Event definitions

Similarly to commands, events are defined in files which names has the `events.proto` suffix:

 * `blog_events.proto` 
 * `order_events.proto`
 * `customer_events.proto`.

### Rejection definitions

`Rejection` is a special — so to say, “negative” — kind of events supported by the framework. 
A rejection is thrown if a command cannot be handled. Think exceptions, but of non-technical flavor.

Similarly to events, rejections are defined in files ending with `rejections.proto`:

  * `blog_rejections.proto` 
{'fraction_non_alphanumeric': 0.07149621212121213, 'fraction_numerical': 0.0, 'mean_word_length': 4.588624338624339, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 7, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '2342852', 'n_tokens_mistral': 1138, 'n_tokens_neox': 1086, 'n_words': 562}