Domain Documentation
Customer wants an application to let people manage their tasks so people can freely register an account and define their tasks to manage them by the app. this is the whole of scenario that the customer told us: I need to first create an organization then create some projects in it, every project must have some boards and every boards can have some cards. I need to define my tasks in that cards and then move the tasks between them. I also need to add any other people to my account as team member and mange their accessibilities to see and perform changes to boards.
By the customer needing, we recognized some entities and their rules as below and we separate them as 2 section: Website and Admin panel
Website is the public side of application that uses by end users. it is the main part of business. We have a simple ER diagram to show the relations between entities but consider that we want to implement a NoSQL database so it can be different if you have a relational vision, it's just to get more knowledge about domain. We will explain more about them in the following.
Members are those want to use the app to manage their tasks. They must register at first then can login and use the features. There are some important rules about members:
- First name, last name, phone number, password and email are required.
- Email needs to validate.
- Email uses as UserName to login.
- Each member can add organizations up to 5.
- Members can add another member to their account as a team member.
- Member can have team members up to 10.
- It doesn't need to have team definition. A team member just refer to someone who has access to another member's account but just to manage the tasks.
- We can ban members in admin panel so they cant get login.
Organization is top level category to hold the tasks. it can be a company name for example. It helps Members who work in more than one company to manages their tasks separately so for managing tasks, the first thing is creating an organization. There are some important rules about organizations:
- Name and OwnerMemberId are required.
- OwnerMemberId is the identity of member who created the organization.
- Each organization can have up to 5 projects.
- Owner can add/delete/update own organizations.
Each organization can have some projects to categorize the tasks as a subcategory. It helps Members who are engaged in more than one project in an organization to manages their tasks separately. There are some important rules about projects:
- Name and OrganizationId are required.
- Each project can have up to 4 boards.
- Just organization owner can add/delete/update projects.
Each Project can have some boards to categorize the tasks as a subcategory. For example if we work on a web application project we might have 3 boards for it like: Admin Panel, Web Site and UX. There are some important rules about boards:
- Name and ProjectId are required.
- Each board can have up to 4 cards.
- Each board can have up to 10,000 tasks.
- Just organization owner can add/delete/update boards.
Each board can have some cards to categorize the tasks as a subcategory. For example in admin panel board we can have 3 cards like: to do, doing, done. There are some important rules about cards:
- Name, Description, BoardId and Type are required.
- Valid values for Type are ToDo, Doing, Done.
- Each card can have up to 2000 tasks.
- Just organization owner can add/delete/update cards.
Each card can have some tasks and members who have access to the boards can add new task to a card or move a task between cards. For example if we finished a task we can move it from Doing card to Done card. We need to have all changes history about task's current state and member who made the changes on it. There are some important rules about tasks:
- Name, Description, CardId are required.
- Just organization owner can delete tasks.
As we said, members can invite another member to have access to their account so they must specify the level of access for invited member. Access level means what boards the invited member can have access. There are some important rules about accessibilities:
- Just account's owner can invite new members
- By default, the account's owner has access to all boards in all projects in all organizations
- Just account's owner can delete an invited member or update invited member's accessibilities
- In each accessibility we determine who has access to what board
Admin panel is the private side of application that uses by admins to manage the whole data in the app. It uses to manage members or reporting and so on. We have a simple ER diagram to show the relations between entities but consider that we want to implement a NoSQL database so it can be different if you have a relational vision, it's just to get more knowledge about domain. We will explain more about them in the following.
Just to know: regarding to the business, administration entity can be out of complexity so it is better to use anemic model instead of rich model and it doesn't need DDD.
Operators are admin panel users. They can manage all data about the app in admin panel. There are some important rules about operators:
- First name, last name, phone number, password and email are required.
- Email needs to validate.
- Email uses as UserName to login.
- Operator can have some Roles.
Role is used to specify admin panel operator's access level. There are some important rules about roles:
- Name is required.
- Role can have some Permissions.
Each permission refer to a feature in admin panel that operator can use it to do something. There are some important rules about permissions:
- Name, SystemName and GroupName are required. Name is for display, SystemName is for using in the code as access filters and GroupName is just to categorize permissions to display.
This document is just for developers how want to know more about the domain and actually its not a complete and real domain documentation so when you check the code you can see any other rules out of this doc but you always can help us to make everything update. There are some public rules that must followed for each entity in the model:
- Check null or empty for required items.
- check input for string items to be valid. for example first name and last name must just contain alphabet chars.
- Check input for email and phone number and so on items to be valid.
- Prevent duplicate data. For example prevent to exist organization with same name for a member.
- Some logical rules that must be done by any clean coder. For example prevent to add data for a member by another authorized member.
- ...
This is an open source project an some times it can have some differences between docs and the source so if you had a problem please tell us in issues or feel free to fix it by a pull request