This documentation is about the Domain Model for TaskoMask. Here we talk about the problem and stakeholder requirements to get more information about the domain. It's here to make understanding the domain model and its implementation in our solution easier.

The stakeholder needs an app that allows users to manage their tasks. Users can freely create accounts and define their tasks using the app. Here are some details the stakeholder provided:

I want to start by creating an organization. Then, within that organization, I want to create projects. Each project should have boards, and these boards can contain cards. I'll define my tasks within these cards and move tasks between them. It's also important to be able to leave comments on tasks and track all activities related to tasks, including their movement between cards.

In this phase of design, we identify subdomains through knowledge crunching methods. Each subdomain has its own characteristic and communicate with others through a contact point.

It's important to note that in our case, we design a domain to be intentionally simple, ensuring it's easy to develop and maintain as an open-source project

In the diagram above, we've identified three subdomains:

• Workspace: This is the most important section. We'll put our best design and effort into it, and our most skilled programmer will handle it.
• Membership: This aspect of the domain is necessary for the system to work correctly, but it's not highly critical. We can assign it to less experienced programmers on the team or even consider outsourcing it.
• Authorization: This is a generic functionality that can be used in various domains. So, we can even utilize an existing 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 (We do that in Tactical Design phase)

🔴Please Note: As refactoring into microservices was becoming challenging to manage, we made the decision to remove the Membership Bounded Context (BC) and all its related components, including the Admin Panel Client, from the source code. However, if you'd like to see how we implemented it, you can review the source code from this last commit before it was removed.

In the Tactical phase of design, we dive into the details within each Bounded Context. We utilize tactical patterns such as Aggregate, Entity, Value Object, and Domain Services to shape these details.

Based on our strategic design, each Bounded Context may have different development requirements, so we need to determine the architecture for each one. In our case, the Workspace Bounded Context is the core domain, and we opted for CQRS to separate Read and Write models. We followed DDD principles for rich domain modeling on the Write side. However, for other subdomains, we simply use a CRUD-based architecture due to their lower importance in our business.

---

We understand that DDD learners often come from a data-driven background. To assist them in better grasping the business concepts, we've provided some Entity-Relationship (ER) diagrams. However, in practical scenarios for knowledge extraction, methods such as Event Storming, Domain Storytelling, and User Story Mapping are more commonly used.

Owners are individuals who wish to use the app for task management. They need to register initially, and after that, they can log in and access the app's features. There are some important business rules that apply to owners:

• First name, last name, phone number, password and email are required.
• Email must be valid.
• Email is used as UserName to login.
• Each owner can add organizations up to 5.

An organization serves as the highest-level category for task management. It can represent a company's name, for instance. Organizations assist owners who are associated with multiple companies in managing their tasks separately. Therefore, the initial step for task management is creating an organization. There are some important business rules that apply to 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.

Within each organization, you can create projects to further categorize tasks into subcategories. This feature benefits owners who are involved in multiple projects within an organization, allowing them to manage their tasks separately. There are some important business rules that apply to projects:

• Name and OrganizationId are required.
• Each project can have up to 4 boards.
• Owner can add/delete/update projects.

Within each project, you can create boards to further categorize tasks into subcategories. For instance, if you're working on a web application project, you might have three boards, such as Admin Panel, Website, and UX. There are some important business rules that apply to boards:

• Name and ProjectId are required.
• Each board can have up to 4 cards.
• Each board can have up to 1000 tasks.
• Owner can add/delete/update boards.

Within each board, you can create boards to further categorize tasks into subcategories. For example, in admin panel board we can have 3 cards like: to do, doing, done. There are some important business rules that apply to cards:

• Name, Description, BoardId and Type are required.
• Valid values for Type are ToDo, Doing, Done.
• Just organization owner can add/delete/update cards.

Within each card, you can create tasks and move them to other cards. There are some important business rules that apply to tasks:

• Name, Description, CardId are required.
• Owner can add/delete/update tasks.

Within each task, you can add comments. There are some important business rules that apply to Comment:

• content is required.

Every task can generate system activities through task-related events. For instance, creating a task is considered an activity, and moving it to different cards triggers a new activity. There are some important business rules that apply to the Activity:

• Description is required.

Operators are users of the admin panel. They have the authority to manage all the data related to the app within the admin panel. There are some important business rules that apply to operator:

• First name, last name, Username, password and email are required.
• Email must be valid.
• Operator can have some Roles.

Role is used to specify operator's access level. There are some important business rules that apply to role:

• Name is required.
• Role can have some Permissions.

Each permission corresponds to a specific feature in the admin panel that operators can use to perform certain actions. There are some important business rules that apply to permissions:

• Name, SystemName and GroupName are required.

🔴Please Note: This document is intended for developers who want to gain a better understanding of the domain. It's important to note that it's not a comprehensive or complete domain documentation. Therefore, when reviewing the code, you may encounter additional rules and details not covered in this document