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.
In this phase of design, we extract some subdomains through knowledge crunching methods. Each subdomain has its own characteristic and communicate with others through a contact point. In our case, we design a domain as simple as enough to be easy to develop and maintain as an open-source project but for yours can be more complex and needs more research on strategic design phase. Also, you can ask your questions about your domain by creating an issue.
In the above diagram, we specified 3 subdomains:
- Workspace: This is the most important part of the domain. We must put the best of our design and effort for it. The best programmer in our team must work on it.
- Membership: This part of the domain is important for system working fine, But it is not very critical. We may assign it to less experienced programmers in the team or even can outsource it.
- Authorization: This is a generic functionality that can be used in any other domains. So we can even use an already existed tool for it.
In the strategic design phase, we focus on the subdomains and their relations and characteristic. We think about the best design for each subdomain through a Bounded Context and define Ubiquitous language for them, then draw Context Mapping etc. But we never think about the details inside the Bounded Contexts. In Tactical phase of design, we draw the details inside each BC. There are some tactical patterns we use for it like: Aggregate, Entity, Value Object, Domain Services, etc.
According to our strategic design, the development requirements for each BC can be different, We must decide what architecture we want to use for each BC. In our case, Workspace BC is the Core domain, and we chose CQRS to separate Read and Write models and then follow DDD rich domain modeling for write side. But for other subdomains, we just use a CRUD base architecture because of their importance level in our business.
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