A service for selecting names and names from an idea to an implementation or Django as a great platform for startups. Continuation
In a previous article, I wrote how the namingservice.org startup started . In this topic, I will continue to describe the next stage of the materialization of the idea. After the document “Vision of the project” was ready, I thought it would be great to transfer the types of the site to paper, that is, how it should look and how I imagined it.
It all started with the look of the home page. It was supposed to give a brief idea about the project, and contain a page header (logo, slogan, navigation, login and registration buttons), plus I decided that it would be useful to display orders directly on the main page with a brief description and price.
The result was a document consisting of 15 types that formed the basis of the site design. What came of this, you can see directly on the site , but in order to feel the difference between what was designed and what happened, I will give a few more basic types.
This document outlined the basic data requirements.
To store personal user preferences, use the standard Django User table.
User accounts reflect the current balance of users. Information stored in user accounts includes:
Transactions keep a history of all operations performed on user accounts. Information stored in transactions includes:
Orders contain all information about incoming, active and already completed orders. The information stored in the orders includes:
It contains all the offers coming from users. The information stored in the offers includes:
* Cardinality - a type of connection (1: M - one to many, M: N - many to many).
** Participation indicator - obligatory, non-obligatory presence of this connection for each tuple (row) of an entity (table) (P - partial participation in the connection, T - full participation in the connection).
The result was a scheme linking the database structure with the Django Framework applications.
This actually ended the project design, after which there was no more strength and patience to design further, and I started writing code in the Django Framework.
Kinds
It all started with the look of the home page. It was supposed to give a brief idea about the project, and contain a page header (logo, slogan, navigation, login and registration buttons), plus I decided that it would be useful to display orders directly on the main page with a brief description and price.
The result was a document consisting of 15 types that formed the basis of the site design. What came of this, you can see directly on the site , but in order to feel the difference between what was designed and what happened, I will give a few more basic types.
View My Orders
My order view
My Account View
Data requirements
This document outlined the basic data requirements.
1 User Profiles
To store personal user preferences, use the standard Django User table.
2 User Accounts
User accounts reflect the current balance of users. Information stored in user accounts includes:
- Amount of funds in the account
- Account currency (may be needed in the future, by default USD)
3 Transactions
Transactions keep a history of all operations performed on user accounts. Information stored in transactions includes:
- date
- A type
- Amount
- Status
- The note
4 orders
Orders contain all information about incoming, active and already completed orders. The information stored in the orders includes:
- Description
- Order Keywords
- Limitations
- Additionally
- Price
- Status
- date of creation
- Date of change
- Language (so that later when translating take this into account when showing)
5 Offers
It contains all the offers coming from users. The information stored in the offers includes:
- Sentence
- Status
- date of creation
- Date of change
6 Entity Types
- Profile
- Score
- Transaction
- Order
- Sentence
7 Types of Relations
| Entity Type | Communication | Entity Type | Cardinality * | Participation rate ** |
|---|---|---|---|---|
| Profile | It has | Score | 1: M | T: T |
| Score | It has | Transaction | 1: M | P: T |
| Profile | It has | Order | 1: M | P: T |
| Profile | It has | Sentence | 1: M | P: T |
| Order | It has | Sentence | 1: M | P: T |
* Cardinality - a type of connection (1: M - one to many, M: N - many to many).
** Participation indicator - obligatory, non-obligatory presence of this connection for each tuple (row) of an entity (table) (P - partial participation in the connection, T - full participation in the connection).
The result was a scheme linking the database structure with the Django Framework applications.
This actually ended the project design, after which there was no more strength and patience to design further, and I started writing code in the Django Framework.