Skip to content

Latest commit

 

History

History
190 lines (140 loc) · 6.39 KB

README.md

File metadata and controls

190 lines (140 loc) · 6.39 KB
Raw

CQRSES_GROUP3

A repository to train on event sourcing, CQRS and DDD. Google Drive for CQRSES_GROUP3

Project setup

If this is the first time you run the project, please go to the .env.dist file and set the variables according to your wishes

then simply run make init

If you need more informations about the available make commands just run make help

Docker Setup

Refer to the DOCKER.md for setup

Useful resources

Google Drive: CQRSES_GROUP3

All the technical documentations and schemes.

Specifications board

All the Epic and User stories

Application board

All the technical tasks

Specification process

  1. The process follow a simple logic: first we create an Epic issue in the specifications board to reference all the correspondent User/Dev-Stories. Some of them are focused for developers, others for users.
  2. Those Epic issues will be described with their initiatives and goals and captures a large amount of work granularized into User/Dev-stories.
  3. Then the User/Dev-stories will be created with the desired behaviour for a specific feature.
  4. Finally, the User/Dev-stories will be breakdown into technical tasks referenced as feature request in the issues list.

All of those issues follow the stages Todo, In Progress, Done

Development process

  1. Most of the time a ticket on the application board in the Todo column is assign to a team member.
  2. When a member starts working on the ticket, he should move the concerned ticket to In Progress.
  3. Then he creates a branch specifically for this ticket with a name that follows the conventions specified below.
  4. Commit regularly at each significant step with unambiguous commit messages (see COMMIT_CONVENTIONS file).
  5. Create a merge request that follows the conventions specified below to the develop branch.
  6. On the application board, move the ticket to the status In Review
  7. Assign the merge request to a maintainer
  8. It may take some back and forth before your pull request will be validated
  9. Your pull request will be then merged into develop branch and the concerned ticket will be moved to Done

Tests

You can run tests using the make test command.

Branch naming convention

You branch should have a name that reflects it's purpose.

It should use the same guidelines as COMMIT_CONVENTIONS (feat, fix, build, perf, docs), followed by an underscore (_) and a very quick summary of the subject in [kebab case][1].

Example: feat_add-image-tag-database-relation.

Pull requests (PR)

Pull requests in this project follow two conventions, you will need to use the templates available in the ISSUE_TEMPLATE folder :

If your pull request is still work in progress, please add "WIP: " (Work In Progress) in front of the title, therefor you inform the maintainers that your work is not done, and we can't merge it.

The naming of the PR should follow the same rules as the COMMIT_CONVENTIONS

Linter

We use go linter gofmt to automatically formats the source code.

API Documentation

Account

Create new account

POST /register
Content-Type: application/json
{
    "name": "John Doe",
    "email": "[email protected]",
    "password": "*********"
}

Log in

POST /login
Content-Type: application/json
{
    "email": "[email protected]",
    "password": "*********",
}

Please note that the token is set inside your cookies and that you need to place it inside the Authorization header of your request, prefixed by 'Bearer ' (the space is important).

Articles

Get article

GET /api/v1/articles/:id

Create new article

POST /api/v1/articles
Content-Type: application/json
{
    "AuthorID": 1,
    "Title": "The best article you'll read today",
    "Content": "In fact it's the best article because it's only one line."
}

Update an existing article

POST /api/v1/articles/:id
Content-Type: application/json
{
    "AuthorID": 1,
    "Title": "The best article you'll read today",
    "Content": "In fact it's the best article because it's only one line."
}

Delete article

DELETE /api/v1/articles/:id

Stack

tool port note
postgres 5432 store the users
go 8000 the app
go 8082 the consumer
adminer 8080 administrate the db
elasticsearch 9200 store the articles
kibana 5601 manage elasticsearch
rabbitmq 15672 - 5672 queuing system

Contributors


Jason Gauvin
Jacques Maarek
Benoît Covet
Edwin Vautier