From 8d3fb415dee52d01d7f7a7704d26c80cc031aba7 Mon Sep 17 00:00:00 2001
From: Radoslav Georgiev <radorado@hacksoft.io>
Date: Sat, 30 Nov 2019 12:39:16 +0200
Subject: [PATCH 1/3] Add naming convention secitons for services/selectors

---
 README.md | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/README.md b/README.md
index 3b6ff11..c0e772a 100644
--- a/README.md
+++ b/README.md
@@ -290,6 +290,34 @@ def create_user(
 
 As you can see, this service calls 2 other services - `create_profile` and `send_confirmation_email`
 
+### Naming convention
+
+Naming conventions depend on your taste. It pays off to have a consistent naming convention through out a project.
+
+If we take the example above, our service is named `create_user`. The pattern is - `<action>_<entity>`.
+
+What we usually prefer in our projects, again, depending on taste, is `<entity>_<action>` or with the example above: `user_create`. This seems odd at first, but it has few nice features:
+
+* Namespacing. It's easy to spot all services starting with `user_` and it's a good idea to put them in a `users.py` module.
+* Greppability. Or in other words, if you want to see all actions for a specific entity, just grep for `user_`.
+
+A full example would look like this:
+
+```python
+def user_create(
+    *,
+    email: str,
+    name: str
+) -> User:
+    user = User(email=email)
+    user.full_clean()
+    user.save()
+
+    profile_create(user=user, name=name)
+    confirmation_email_send(user=user)
+
+    return user
+```
 
 ## Selectors
 
@@ -314,6 +342,11 @@ def get_users(*, fetched_by: User) -> Iterable[User]:
 
 As you can see, `get_visible_users_for` is another selector.
 
+
+### Naming convention
+
+Read the section in services. Same rules apply here.
+
 ## APIs & Serializers
 
 When using services & selectors, all of your APIs should look simple & identical.

From dd6ffdd50dce484f56b7ab2f112699149df755e1 Mon Sep 17 00:00:00 2001
From: Radoslav Georgiev <radorado@hacksoft.io>
Date: Sat, 30 Nov 2019 12:44:37 +0200
Subject: [PATCH 2/3] Add naming convention for APIs

---
 README.md | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/README.md b/README.md
index c0e772a..0b7faf9 100644
--- a/README.md
+++ b/README.md
@@ -363,6 +363,12 @@ General rules for an API is:
   * Reuse serializers as little as possible
   * If you need a nested serializer, use the `inline_serializer` util
 
+### Naming convention
+
+For our APIs we use the following naming convention: `<Entity><Action>Api`.
+
+Here are few examples: `UserCreateApi`, `UserSendResetPasswordApi`, `UserDeactivateApi`, etc.
+
 ### An example list API
 
 ```python

From 9c6bf84825321157c89662ec4ddad7309b3aaba2 Mon Sep 17 00:00:00 2001
From: Radoslav Georgiev <radorado@hacksoft.io>
Date: Mon, 2 Dec 2019 11:49:58 +0200
Subject: [PATCH 3/3] Add TOC for naming conventions

---
 README.md | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/README.md b/README.md
index 0b7faf9..94a154b 100644
--- a/README.md
+++ b/README.md
@@ -16,8 +16,11 @@ Expect often updates as we discuss & decide upon different things.
   * [Methods](#methods)
   * [Testing](#testing)
 - [Services](#services)
+  * [Naming convention](#naming-convention)
 - [Selectors](#selectors)
+  * [Naming convention](#naming-convention-1)
 - [APIs & Serializers](#apis--serializers)
+  * [Naming convention](#naming-convention-2)
   * [An example list API](#an-example-list-api)
   * [An example detail API](#an-example-detail-api)
   * [An example create API](#an-example-create-api)