LogoLogo
  • AppFlowy
    • ⭐Start here
      • Welcome to AppFlowy Docs
      • How to get help
      • Install AppFlowy
    • 🛠️Installation
      • 🖥️System Requirements
      • 💿Installation methods
        • Mac / Windows / Linux Packages
          • Installing on Linux
            • Installing & Setting up Flutter on Linux from Source
        • Docker
    • 🌱Community
      • 🤙Get in contact
      • 📔AppFlowy Mentorship Program
        • Program Guidance
        • Proposal Template
        • Pull Request Template
        • Mentorship 2023
          • Mentee Projects
            • Calendar View for AppFlowy Database
            • Custom Themes
            • Shortcuts and Customized Hotkeys for AppFlowy
            • Table
            • ⭐Favorites
            • Code Block
            • Outlines
            • Importers
            • AI Writers
            • Templates
          • Project Ideas
      • ✍️Write for AppFlowy
        • 📃Drafts
          • [Draft] Use Case: Software Engineer
          • [Draft] Use Case: High School Students
          • [Draft] How to add a new property to appflowy database
      • 🍂Hacktoberfest
    • 🛣️Roadmap
    • 🌋Product
      • 💽Data Storage
      • 🎨Customize and Style Content
      • ⏮️Duplicate, Delete, and Restore
      • 💎Databases
        • 🔢Database Properties
        • 🗃️Manage Properties
      • Ⓜ️Markdown
      • ⌨️Shortcuts
      • 🪄AppFlowy AI
      • 🦙AppFlowy Local AI - Ollama
      • 🎨Themes
      • ☁️AppFlowy Cloud
      • 🧩AppFlowy Plugins
        • Table-view Databases
        • Kanban Board
        • Calendar
        • Auto Generator
        • Smart Edit
        • Code Blocks
        • Math Equations
        • Cover
        • Emoji
  • Documentation
    • 💎Software Contributions
      • 🟢Get started
      • 💀Architecture
        • Frontend
          • Tauri
            • 🗺️CodeMap
          • Web
            • 🌟Design Philosophy
          • Flutter
            • 🗺️Project Structure: CodeMap
            • 🧮Grid
            • ⚙️Setting
          • Inter-Process Communication
          • User
            • User Data
            • Events & Notifications
          • Folder
            • Events & Notifications
          • Document
          • Database View
            • Events & Notifications
            • Grid
            • Calendar
            • Kanban Board
        • Backend
          • Initialize
          • Events
          • Delta(WIP)
          • Profiling
          • Database
        • Domain Driven Design
        • Proposals
      • 🏗️Conventions
        • 🔤Naming Conventions
        • ⌨️Code Conventions
          • 🐦Flutter
        • 🐙Git Conventions
      • 💛Submitting Code
        • 🏦Setting Up Your Repositories
        • ⤴️Submitting your first Pull Request
      • 🤟Coding Standards and Practices
        • 👽Rust Backend
    • 🚀AppFlowy
      • 👾How to contribute to AppFlowy
      • 🏗️Building from Source
        • 🌳Flutter Setup
          • 🐧Building on Linux
          • 🍎Building on macOS
          • 🪟Building on Windows
        • 🌐Web Setup
        • 📡Tauri Setup
      • ☁️Debugging with AppFlowy Cloud
      • 🔁Debugging in VS Code
      • ☎️Translate AppFlowy
      • ❓Troubleshooting
      • 👮‍♀️Licenses
    • 🏍️AppFlowy Editor
      • ⌨️How to Implement Markdown Syntax To Style Text In AppFlowy Editor
      • 🧩How to Create a Plugin for AppFlowy Editor
      • 👮‍♀️Licenses
    • ☁️AppFlowy Cloud
      • 🌈Architecture
      • ☀️Deployment
  • Guides
    • Sync Desktop and Mobile
    • Self-Hosting AppFlowy
      • ☁️Self-hosting AppFlowy with AppFlowy Cloud
      • 🆓Self-hosting AppFlowy for free Using Supabase
    • Import From Notion
  • Blog Highlights
    • 🔮Demystifying AppFlowy Editor's Codebase
  • Handbook
    • Core values
Powered by GitBook
On this page
  • Layered architecture
  • Presentation Layer:
  • Application Layer:
  • Domain Layer:
  • Infrastructure Layer:
  • Data Model
  • Relation
  • Operation Flow

Was this helpful?

Edit on GitHub
  1. Documentation
  2. Software Contributions
  3. Architecture

Domain Driven Design

PreviousDatabaseNextProposals

Last updated 3 years ago

Was this helpful?

For many architects, the process of data modeling is driven by intuition. However, there are well-formulated methodologies for approaching it more formally. We chose for AppFlowy's architecture.

Layered architecture

The most common architecture pattern is the layered architecture pattern, known as the n-tier architecture pattern, where we partition the software into layers to reduce the complexity. Each layer of the layered architecture pattern has a specific role and responsibility.DDD consists of four layers.

file : ddd_layered_achitecture.wsd

Presentation Layer:

  • Responsible for presenting information to the user and interpreting user commands.

  • Consists of Widgets and also the state of the Widgets.

Application Layer:

  • Defines the jobs the software is supposed to do. (Shouldn't find any UI code or network code)

  • Coordinates the application activity and delegates work to the next layer down.

  • It doesn't contain any complex business logic but the basic validation of user input before passing it to the other layers.

Domain Layer:

  • Responsible for representing concepts of the business.

  • Manages the business state or delegates to the infrastructure layer.

  • Self contained and it doesn't depend on any other layers. The Domain layer should be well isolated from the other layers.

Infrastructure Layer:

  • Persists application data by implementing the repository interfaces provided by the Domain layer.

  • Provides generic technical capabilities that support the higher layers. It deals with APIs, persistence and network, etc.

  • Hides the complexity of the Domain layer.

                 ▲
                 │
    Level of     ├───────────────────┐
    Abstraction  │ Presentation      │
                 ├───────────────────┴───────┐
                 │ Application               │
                 ├───────────────────────────┴─────────┐
                 │ Domain                              │
                 ├─────────────────────────────────────┴────────┐
                 │ Infrastructure                               │
                 └──────────────────────────────────────────────┴─────▶
                                                           Complexity

Data Model

DDD classifies data as referenceable objects, or entities, and non-referenceable objects, or value objects. Let's introduce some DDD terminology.

Entity

Entities are plain objects that carry an identity which allows us to reference them. e.g. user, order, book, etc. You use entities to express your business model and encapsulate them into Factory that provides a simple API to create Entities.

Value Object

Value Object can't be referenced. They can be only included into entities and serve as attributes. Value objects should be simple and treated as immutable. e.g. email, phone number, name, etc.

Aggregate

Entities and Value objects can be grouped into aggregates. Aggregates can simplify the model by accessing the entire aggregate. For instance, Table has lots of rows. Each row using the table_id to reference to the table. TableAggregate includes two entities: Table and the Row.

     TableAggregate
    ┌────────────────────────────────────────────────────────────────┐
    │                                                                │
    │  ┌────────────────────┐         ┌─────────────────────────┐    │
    │  │struct Table {      │         │struct Row {             │    │
    │  │    id: String,     │         │    table_id: String,    │    │
    │  │    desc: String,   │◀▶───────│}                        │    │
    │  │}                   │         │                         │    │
    │  └────────────────────┘         └─────────────────────────┘    │
    │                                                                │
    └────────────────────────────────────────────────────────────────┘

Service

When a significant process of transformation in the domain is not a natural responsibility of an Entity or Value object, add an operation to the model as standalone interface declared as a Service. For instance: The Value object EmailAddress uses the function validateEmailAddress to verify if the email address is valid or not. Services exist in the Application, Domain and Infrastructure layers.

class EmailAddress  {
  final Either<Failure<String>, String> value;

  factory EmailAddress(String? input) {
    return EmailAddress._(
      validateEmailAddress(input),
    );
  }

  const EmailAddress._(this.value);
}


Either<Failure<String>, String> validateEmailAddress(String? input) {
  ...
}

Repository

Repositories offer an interface to retrieve and persist aggregates and entities. They hide the database or network details from the domain.

Repository interfaces are declared in the Domain Layer, but the repositories themselves are implemented in the Infrastructure Layer. You can replace the interface implementation without impacting the domain layer.

For instance:

// Interface:
abstract class AuthInterface {
    ...
}

// Implementation
class AuthRepository implements AuthInterface {
    ...
}

More often than not, the repository interface can be divided into sub-repository in order to reduce the complexity.

Relation

The diagram below is a navigational map. It shows the patterns that form the building blocks of Domain Driven Design and how they relate to each other.

Operation Flow

       presentation       │          Application                      domain                        Infrastructure
                                                      │                                   │
                             7                                 Data Model
               ┌──────────────────────────────┐       │       ┌────────────────────────┐  │     ┌─────────────────────┐
               │          │                   │               │ ┌─────────────┐        │        │   Network Service   │
               ▼             Bloc             │       │       │ │  Aggregate  │        │  │     └─────────────────────┘
        ┌─────────────┐   │ ┌─────────────────┴─────┐         │ └─────────────┘        │                   ▲
────────▶   Widget    │     │ ┌────────┐ ┌────────┐ │    2    │ ┌────────┐             │  │                │ 6
        └─────────────┘   │ │ │ Event  │ │ State  │ │────┬───▶│ │ Entity │             │        ┌─────────────────────┐
User           │            │ └────────┘ └────────┘ │ │  │    │ └────────┘             │  │     │ Persistence Service │
interaction    │          │ └──────▲────────────────┘    │    │ ┌─────────────────┐    │        └─────────────────────┘
               │                   │                  │  │    │ │  Value Object   │    │  │                ▲
               └──────────┼────────┘                     │    │ └─────────────────┘    │                   │ 5
                     1                                │  │    └────────────◈───────────┘  │     ┌─────────────────────┐
                          │                              │                 │contain             │    Unit of Work     │
                                                      │  │      ┌────────────────────┐    │     └─────────────────────┘
                          │                              │      │      Service       │                     ▲
                                                      │  │      └────────────────────┘    │                │
                          │                              │                                                 │ 4
                                                      │  │     Repository                 │                │
                          │                              │   ┌─────────────────────────────────────────────┴───────────────┐
                                                      │  │   │ ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐  3  ┌ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┐ │
                          │                              └───┤         Interface        ────▶       Implementation         │
                                                      │      │ └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘     └ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┘ │
                          │                                  └─────────────────────────────────────────────────────────────┘
                                                      │

2. The bloc processes the events using the services provided by the Domain layer.

  1. Convert DTO (Data Transfer Object) to domain model and Domain Model to DTO.

  2. Domain model is the place where all your business logic, business validation and business behaviors will be implemented. The Aggregate Roots, Entities and Value Objects will help to achieve the business logic.

3. Calling repositories to perform additional operations. The repositories interfaces are declared in the Domain layer and are implemented in the Infrastructure layer. You can reimplement the repository interface with different languages, such as Rust, C++ or Dart. etc.

  1. Handling operations (INSERT, UPDATE and DELETE) with SQLite to persis the data.

  2. Saving or querying the data in the cloud to finish the operation.

AppFlowy is composed in layers, where higher layers use the facilities provided by lower layers. Each layer provides a different abstraction from the layer above and below it. As you can see, the Complexity and Abstraction of these layers are depicted in the following diagram. As developers, we should pull the complexity downwards. Simple interfaces and powerful implementations (Think about the function). Another way of expressing this idea is that it is more important for a module to have a simple interface than a simple implementation.

Widget accepts user interaction and translates the interactions into specific Events. The events will be sent to the Application layer, handled by the specific bloc. The bloc sends the states changed by the events back to the widget, and finally the Widget updates the UI according to the state. The pattern is depicted in this diagram. (More about the flutter )

file : DDDBlocCPattern.svg
file : DDDRepositoryImplementsInterface.svg

4. The responsibility of is to maintain a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems((No intermediate state)). If any one persistence service fails, the whole transaction will be failed so, roll back operation will be called to put the object back in initial state.

💎
💀
open
bloc
Unit of Work
💥
Domain-Driven Design