Domain Documentation
This documentation is related to Domain Model for TaskoMask. Here we talk about the problem space and stakeholder requirement to get more information about the domain. Actually, it is just to help better understanding for the domain model and how it is implemented in solution space.
Stakeholder 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 the scenario that the stakeholder told us:
I need to first create an organization then create some projects in it, every project must have some boards and every board can have some cards. I need to define my tasks in that cards and then move the tasks between them. It's need to leave comments on the tasks and I need to see every activity for the tasks like moving between cards and so on.
Also, Stakeholder needs a Website to introduce the product and an Admin Panel to manage the whole data.
Considering that the DDD learners usually come from data driven paradigm, here we have tried to help them understand business better by presenting some ER diagrams. But, in a real world for knowledge extraction there are some methods we can use like Event storming, Domain storytelling and User story mapping
Owners are those want to use the app to manage their tasks. They must register at the first, then can login and use the features. There are some important rules about owners:
- First name, last name, phone number, password and email are required.
- Email needs to validate.
- Email uses as UserName to login.
- Each owner can add organizations up to 5.
- We can ban owners in admin panel, so they can't get login.
Organization is top level category to hold the tasks. It can be a company name, for example. It helps Owners who work in more than one company to manage their tasks separately, so for managing tasks, the first thing is creating an organization. There are some important rules about organizations:
- Name and OwnerId are required.
- OwnerId is the identity of owner 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 Owners 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, Website 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 1000 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.
- Just organization owner can add/delete/update cards.
Each card can have some tasks, and owners who have access to the boards can add a 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 owner who made the changes on it. There are some important rules about tasks:
- Name, Description, CardId are required.
- Just organization owner can delete tasks.
Each task can have some comments. There are some important rules about Comment:
- content is required.
Each task can have some activities created by the system through the task events. For example, creating the task is an activity and move it to another card is a new activity. There are some important rules about the Activity:
- name is required.
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, Username, password and email are required.
- Email needs to validate.
- 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 it's 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 an organization with same name for an owner.
- Some logical rules that must be done by any clean coder. For example, prevent to add data for an owner by another authorized owner.
- ...
This is an open source project, and sometimes 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