DEV Community: ma2mori

When Asked How to Learn Programming, This Is My Answer

ma2mori — Thu, 04 Sep 2025 01:30:42 +0000

How Should I Learn Programming?

I sometimes get asked this question, and my answer is simple.

"Build the same app (theme) multiple times using different methods."

Why Build the Same Thing Repeatedly?

A common failure in programming learning is "tutorial fatigue."

You build a chat app with React, then an e-commerce site with Rails, then a blog... If you're only following tutorials, you've barely learned anything. Something might be working, but you don't feel like you could build it from scratch.

Instead, I think it's more effective to focus on one thing, like a ToDo app (though it could be anything).

When you build with the same theme, the requirements are clear so you can focus on the technical differences. You can compare with your previous implementation and gradually increase complexity. It also shows your growth clearly as a portfolio.

Recommended Learning Steps

Step 1: Build with Plain HTML + PHP

Start from the simplest approach.

// todo.php
<?php
session_start();
if (!isset($_SESSION['todos'])) {
    $_SESSION['todos'] = [];
}

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (isset($_POST['task'])) {
        $_SESSION['todos'][] = $_POST['task'];
    }
}
?>
<!DOCTYPE html>
<html>
<body>
    <form method="post">
        <input type="text" name="task">
        <button type="submit">Add</button>
    </form>
    <ul>
        <?php foreach ($_SESSION['todos'] as $todo): ?>
            <li><?= htmlspecialchars($todo) ?></li>
        <?php endforeach; ?>
    </ul>
</body>
</html>

You'll touch on the basic mechanisms of web apps like form submission and session management.

Step 2: Add Persistence with Plain PHP + MySQL

Move from sessions to a database.

// todo_db.php
$pdo = new PDO('mysql:host=localhost;dbname=todo', 'root', '');

if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    if (isset($_POST['task'])) {
        $stmt = $pdo->prepare("INSERT INTO todos (task) VALUES (?)");
        $stmt->execute([$_POST['task']]);
    }
    if (isset($_POST['delete'])) {
        $stmt = $pdo->prepare("DELETE FROM todos WHERE id = ?");
        $stmt->execute([$_POST['delete']]);
    }
}

$todos = $pdo->query("SELECT * FROM todos")->fetchAll();

You can understand SQL basics, database connections, and CRUD operations in their raw state.

Step 3: Rebuild with Laravel

Try using a framework.

// routes/web.php
Route::get('/todos', [TodoController::class, 'index']);
Route::post('/todos', [TodoController::class, 'store']);
Route::delete('/todos/{id}', [TodoController::class, 'destroy']);

You'll learn MVC pattern, routing, migrations, and ORM.

Step 4: Deploy on a Rental Server

Try deploying what you've built.

# .htaccess configuration
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L]

Upload via SFTP to a rental server (about $5/month), configure custom domains, install SSL certificates, manage environment variables with .env files - you'll gain knowledge necessary for production operations. This might also be when you encounter the ~~evil~~ complex UIs of domain registrar services.

I recommend researching SQL injection and XSS before going public and reviewing your entire source code.

Step 5: Build with Laravel (API) + Vue.js

Try separating backend and frontend.

// TodoList.vue
export default {
  data() {
    return {
      todos: [],
    };
  },
  mounted() {
    fetch("/api/todos")
      .then((res) => res.json())
      .then((data) => (this.todos = data));
  },
};

You'll learn API design, CORS, asynchronous processing, and component design.

Step 6: Build with Spring Boot + React

Test if you can do the same thing in a different language.

@RestController
@RequestMapping("/api/todos")
public class TodoController {
    @GetMapping
    public List<Todo> getTodos() {
        return todoService.findAll();
    }
}

You'll learn statically typed languages, DI containers, and annotations.

Step 7: Build a CI/CD Pipeline

Implement automatic deployment with GitHub Actions or CircleCI.

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Build and Deploy
        run: |
          npm run build
          npm run deploy

Automatic test execution, build, and deployment on push. You'll learn about using production and staging environments, rollback strategies, and security scanning (vulnerability checks for dependencies).

Step 8: Continuous Feature Addition

With your favorite tech stack, implement user authentication, real-time sync, tagging, search functionality, mobile app version, etc.

Or you might try setting up regular backups and implementing error monitoring tools.

By this point, you'll have acquired the foundations of development.

Why a ToDo App?

Some people say "Building a ToDo app won't teach you much," but they're wrong.

ToDo apps include CRUD operations (Create, Read, Update, Delete), state management, list display, form processing, and data persistence - all the basic elements needed in real work.

Every app basically starts with CRUD operations.

You don't have to stick with a ToDo app though. Any theme you want to build repeatedly is fine.

Learning Resources

Django Girls Tutorial

https://tutorial.djangogirls.org/en/

I really recommend this. It's a tutorial for Python and the Django framework, but its value goes beyond learning language and framework usage.

This tutorial starts with "How does the Internet work?" It explains command line usage with a "the black screen isn't scary" approach. It explains from the level of "What's a folder?" and "What's a file?" and even includes what to do when errors occur. Like "Don't panic if you see this error."

It's written in friendly, conversational language and conveys the message that "programming isn't difficult."

Even people who want to learn PHP or Java should read this first. You'll gain knowledge needed regardless of language - basic programming concepts, how web apps work, and how to set up development environments.

It's a tutorial for building a blog app, but once you understand it, you'll be able to build at least a ToDo app in any language.

After studying for a while, if you read it again, you'll better appreciate how it explains things at just the right level of detail for beginners.

Official Documentation

When you're stuck, checking official documentation first is usually fastest.

Books

Surprisingly, there are quite a few technical books available on Kindle Unlimited, so I recommend it. Universal books may be a bit pricey, but they last long. Buying used is also an option. A recent book, "Tidy First?", not only covers important concepts but also introduces many immediately useful tips, so I recommend it for beginners.

YouTube

Search for "Laravel Todo" or "React Todo" and you'll find tons of tutorials.

Udemy

About $15 during sales. If you've struggled with environment setup, following along with videos might be better. Some instructors frequently answer questions while others don't respond at all, so check carefully before purchasing.

About Schools and Mentors

Honestly, I don't think most people need them.

Looking into it, there seem to be services where designated mentors answer questions for about $10/month, but you tend to develop a dependency mindset of "asking someone."

I also don't recommend expensive schools. With $5,000, you could buy a MacBook Air, 50 technical books, and still have change left over.

Some might think schools are better because they provide job placement support, but consider the downside of choosing from jobs the school introduces. I think you'll be more satisfied if you take time to search for companies to work at without relying too much on others' opinions and apply yourself.

For problems difficult to solve on your own, ask AI. It responds instantly even at midnight.

About Development Environment

For PCs and such, almost anything works (though you basically need a Mac if you want to build and publish iOS apps). Buy a used laptop for about $200, buy $50-100 worth of memory to upgrade it, and it'll last 2-3 years. You can usually find upgrade methods by searching the model number on YouTube. If you want to minimize initial costs, you can significantly reduce expenses by using cloud development environments like Cloud9 or Codespaces, or VDI services like Amazon WorkSpaces from a cheap tablet.

However, many technical articles only verify operation on Mac, so if you have the budget, you might consider a Mac.

I don't spend much on hobbies, and while I use a provided MacBook Pro for work, for personal use I was using a used Dynabook until recently. As it gradually started shutting down randomly and became harder to charge, I bought a Mac mini. It's comfortable but quite expensive.

When You Feel Like Giving Up

Programming learning is lonely. But that's okay.

Struggling with errors, poring over documentation, trial and error. This process is important.

If it gets really tough, take a week off. Step away from programming and come back. That's fine. If you start learning with C# and find it difficult, try touching another language like JavaScript. What's important is being able to continue and finding it at least somewhat interesting.

Summary

In the end, it's all about getting your hands dirty.

When asked "How should I learn programming?", I answer:

"Build the same app (theme) multiple times using different methods."

Even if each version is simple, if you can explain in your own words why you built them in that order and what you learned, that becomes a respectable portfolio. It shows more potential than a seemingly rich e-commerce site built following tutorials that you can't explain the contents of.

Rather than reading popular but incomprehensible advanced books and feeling like you've studied, it's better to learn gradually while coding, periodically stopping to read books to systematically organize your knowledge. Reading books isn't the goal - it's a means to broaden your judgment range during design and implementation.

You don't need expensive tuition. All you need is time to code.

Refactoring based on design principles: example of a data collection crawler system

ma2mori — Fri, 19 Jul 2024 15:20:32 +0000

Introduction

Improving code quality is always an important issue in software development. In this article, we take a data collection crawler system as an example and explain specifically how to apply design principles and best practices through step-by-step refactoring.

Code before improvement

First, we start with a very simple web scraper with all functionality integrated into one class.

Translated with DeepL.com (free version)

project_root/
├── web_scraper.py
├── main.py
└── requirements.txt

web_scraper.py

import requests
import json
import sqlite3

class WebScraper:
    def __init__(self, url):
        self.url = url

    def fetch_data(self):
        response = requests.get(self.url)
        data = response.text
        parsed_data = self.parse_data(data)
        enriched_data = self.enrich_data(parsed_data)
        self.save_data(enriched_data)
        return enriched_data

    def parse_data(self, data):
        return json.loads(data)

    def enrich_data(self, data):
        # Apply business logic here
        # Example: extract only data containing specific keywords
        return {k: v for k, v in data.items() if 'important' in v.lower()}

    def save_data(self, data):
        conn = sqlite3.connect('test.db')
        cursor = conn.cursor()
        cursor.execute('INSERT INTO data (json_data) VALUES (?)', (json.dumps(data),))
        conn.commit()
        conn.close()

main.py

from web_scraper import WebScraper

def main():
    scraper = WebScraper('https://example.com/api/data')
    data = scraper.fetch_data()
    print(data)

if __name__ == "__main__":
    main()

Points to be improved

Violates the principle of single responsibility: one class is responsible for all data acquisition, analysis, enrichment, and storage
Unclear business logic: business logic is embedded in the enrich_data method, but mixed with other processing
Lack of reusability: functions are tightly coupled, making individual reuse difficult
Testing difficulties: difficult to test individual functions independently
Configuration rigidity: database paths and other settings are embedded directly in the code

Refactoring phase

1. Separation of responsibilities: separation of data acquisition, analysis, and storage

Major Change: Separation of responsibilities for data acquisition, analysis, and storage into separate classes
Objective: Apply single responsibility principle, introduce environmental variables

directory structure

project_root/
├── data_fetcher.py
├── data_parser.py
├── data_saver.py
├── data_enricher.py
├── web_scraper.py
├── main.py
└── requirements.txt

data_enricher.py

class DataEnricher:
    def enrich(self, data):
        return {k: v for k, v in data.items() if 'important' in v.lower()}

web_scraper.py

from data_fetcher import DataFetcher
from data_parser import DataParser
from data_enricher import DataEnricher
from data_saver import DataSaver

class WebScraper:
    def __init__(self, url):
        self.url = url
        self.fetcher = DataFetcher()
        self.parser = DataParser()
        self.enricher = DataEnricher()
        self.saver = DataSaver()

    def fetch_data(self):
        raw_data = self.fetcher.fetch(self.url)
        parsed_data = self.parser.parse(raw_data)
        enriched_data = self.enricher.enrich(parsed_data)
        self.saver.save(enriched_data)
        return enriched_data

This change clarifies the responsibilities of each class and improves reusability and testability. However, the business logic is still embedded in the DataEnricher class.

2. introduction of interfaces and dependency injection

Main change: Introduce interfaces and implement dependency injection.
Purpose: increase flexibility and extensibility, extend environment variables, abstract business logic

directory structure

project_root/
├── interfaces/
│   ├── __init__.py
│   ├── data_fetcher_interface.py
│   ├── data_parser_interface.py
│   ├── data_enricher_interface.py
│   └── data_saver_interface.py
├── implementations/
│   ├── __init__.py
│   ├── http_data_fetcher.py
│   ├── json_data_parser.py
│   ├── keyword_data_enricher.py
│   └── sqlite_data_saver.py
├── web_scraper.py
├── main.py
└── requirements.txt

interfaces/data_fetcher_interface.py

from abc import ABC, abstractmethod

class DataFetcherInterface(ABC):
    @abstractmethod
    def fetch(self, url: str) -> str:
        pass

interfaces/data_parser_interface.py

from abc import ABC, abstractmethod
from typing import Dict, Any

class DataParserInterface(ABC):
    @abstractmethod
    def parse(self, raw_data: str) -> Dict[str, Any]:
        pass

interfaces/data_enricher_interface.py

from abc import ABC, abstractmethod
from typing import Dict, Any

class DataEnricherInterface(ABC):
    @abstractmethod
    def enrich(self, data: Dict[str, Any]) -> Dict[str, Any]:
        pass

interfaces/data_saver_interface.py

from abc import ABC, abstractmethod
from typing import Dict, Any

class DataSaverInterface(ABC):
    @abstractmethod
    def save(self, data: Dict[str, Any]) -> None:
        pass

implementations/keyword_data_enricher.py

import os
from interfaces.data_enricher_interface import DataEnricherInterface

class KeywordDataEnricher(DataEnricherInterface):
    def __init__(self):
        self.keyword = os.getenv('IMPORTANT_KEYWORD', 'important')

    def enrich(self, data):
        return {k: v for k, v in data.items() if self.keyword in str(v).lower()}

web_scraper.py

from interfaces.data_fetcher_interface import DataFetcherInterface
from interfaces.data_parser_interface import DataParserInterface
from interfaces.data_enricher_interface import DataEnricherInterface
from interfaces.data_saver_interface import DataSaverInterface

class WebScraper:
    def __init__(self, fetcher: DataFetcherInterface, parser: DataParserInterface, 
                 enricher: DataEnricherInterface, saver: DataSaverInterface):
        self.fetcher = fetcher
        self.parser = parser
        self.enricher = enricher
        self.saver = saver

    def fetch_data(self, url):
        raw_data = self.fetcher.fetch(url)
        parsed_data = self.parser.parse(raw_data)
        enriched_data = self.enricher.enrich(parsed_data)
        self.saver.save(enriched_data)
        return enriched_data

The main changes at this stage are

introduction of an interface to facilitate switching to different implementations
dependency injection to make the WebScraper class more flexible
The fetch_data method has been changed to take url as an argument, making URL specification more flexible.
Business logic has been abstracted as DataEnricherInterface and implemented as KeywordDataEnricher.
The business logic has been made more flexible by allowing keywords to be set using environment variables.

These changes have greatly improved the flexibility and extensibility of the system. However, the business logic remains embedded in the DataEnricherInterface and its implementation. The next step is to further separate this business logic and clearly define it as a domain layer.

3. introduction of domain layer and separation of business logic

In the previous step, the introduction of interfaces increased the flexibility of the system. However, the business logic (in this case, data importance determination and filtering) is still treated as part of the data layer. Based on the concept of domain-driven design, treating this business logic as the central concept of the system and implementing it as an independent domain layer provides the following benefits

centralized management of business logic
more expressive code through the domain model
greater flexibility for changing business rules
ease of testing

Updated directory structure:

project_root/
├── domain/
│   ├── __init__.py
│   ├── scraped_data.py
│   └── data_enrichment_service.py
├── data/
│   ├── __init__.py
│   ├── interfaces/
│   │   ├── __init__.py
│   │   ├── data_fetcher_interface.py
│   │   ├── data_parser_interface.py
│   │   └── data_saver_interface.py
│   ├── implementations/
│   │   ├── __init__.py
│   │   ├── http_data_fetcher.py
│   │   ├── json_data_parser.py
│   │   └── sqlite_data_saver.py
├── application/
│   ├── __init__.py
│   └── web_scraper.py
├── main.py
└── requirements.txt

At this stage, the roles of DataEnricherInterface and KeywordDataEnricher will be moved to the ScrapedData model and DataEnrichmentService at the domain layer. Details of this change are provided below.

Before change (Section 2)

class DataEnricherInterface(ABC):
    @abstractmethod
    def enrich(self, data: Dict[str, Any]) -> Dict[str, Any]:
        pass

class KeywordDataEnricher(DataEnricherInterface):
    def __init__(self):
        self.keyword = os.getenv('IMPORTANT_KEYWORD', 'important')

    def enrich(self, data):
        return {k: v for k, v in data.items() if self.keyword in str(v).lower()}

After modification (Section 3)

@dataclass
class ScrapedData:
    content: Dict[str, Any]
    source_url: str

    def is_important(self) -> bool:
        important_keyword = os.getenv('IMPORTANT_KEYWORD', 'important')
        return any(important_keyword in str(v).lower() for v in self.content.values())

class DataEnrichmentService:
    def __init__(self):
        self.important_keyword = os.getenv('IMPORTANT_KEYWORD', 'important')

    def enrich(self, data: ScrapedData) -> ScrapedData:
        if data.is_important():
            enriched_content = {k: v for k, v in data.content.items() if self.important_keyword in str(v).lower()}
            return ScrapedData(content=enriched_content, source_url=data.source_url)
        return data

This change improves the following.

business logic has been moved to the domain layer, eliminating the need for a DataEnricherInterface.
the KeywordDataEnricher functionality has been merged into the DataEnrichmentService, centralizing the business logic in one place.
The is_important method has been added to the ScrapedData model. This makes the domain model itself responsible for determining the importance of data and makes the domain concept clearer.
DataEnrichmentService now handles ScrapedData objects directly, improving type safety.

The WebScraper class will also be updated to reflect this change.

from data.interfaces.data_fetcher_interface import DataFetcherInterface
from data.interfaces.data_parser_interface import DataParserInterface
from data.interfaces.data_saver_interface import DataSaverInterface
from domain.scraped_data import ScrapedData
from domain.data_enrichment_service import DataEnrichmentService

class WebScraper:
    def __init__(self, fetcher: DataFetcherInterface, parser: DataParserInterface, 
                 saver: DataSaverInterface, enrichment_service: DataEnrichmentService):
        self.fetcher = fetcher
        self.parser = parser
        self.saver = saver
        self.enrichment_service = enrichment_service

    def fetch_data(self, url: str) -> ScrapedData:
        raw_data = self.fetcher.fetch(url)
        parsed_data = self.parser.parse(raw_data)
        scraped_data = ScrapedData(content=parsed_data, source_url=url)
        enriched_data = self.enrichment_service.enrich(scraped_data)
        self.saver.save(enriched_data)
        return enriched_data

This change completely shifts the business logic from the data layer to the domain layer, giving the system a clearer structure. The removal of the DataEnricherInterface and the introduction of the DataEnrichmentService are not just interface replacements, but fundamental changes in the way business logic is handled.

Summary

This article has demonstrated how to improve code quality and apply design principles specifically through a step-by-step refactoring process for the data collection crawler system. The main areas of improvement are as follows.

Separation of Responsibility: Applying the principle of single responsibility, we separated data acquisition, parsing, enrichment, and storage into separate classes.
Introduction of interfaces and dependency injection: greatly increased the flexibility and scalability of the system, making it easier to switch to different implementations.
Introduction of domain model and services: clearly separated the business logic and defined the core concepts of the system.
Adoption of Layered Architecture: Clearly separated the domain, data, and application layers and defined the responsibilities of each layer. 5.Maintain interfaces: Maintained abstraction at the data layer to ensure flexibility in implementation.

These improvements have greatly enhanced the system's modularity, reusability, testability, maintainability, and scalability. In particular, by applying some concepts of domain-driven design, the business logic became clearer and the structure was more flexible to accommodate future changes in requirements. At the same time, by maintaining the interfaces, we ensured the flexibility to easily change and extend the data layer implementation.

It is important to note that this refactoring process is not a one-time event, but part of a continuous improvement process. Depending on the size and complexity of the project, it is important to adopt design principles and DDD concepts at the appropriate level and to make incremental improvements.

Finally, the approach presented in this article can be applied to a wide variety of software projects, not just data collection crawlers. We encourage you to use them as a reference as you work to improve code quality and design.

Domain Driven Design (DDD) with stakeholders: using content production contracting as an example

ma2mori — Wed, 19 Jun 2024 23:50:47 +0000

In my previous article, I focused on the development part of DDD, but this time I would like to delve into the preliminary part. So, using the business challenges of a fictitious company as an example, we will consider how to understand the business process and how to leverage the knowledge of experts to build a system.

Step 0: How the Project Begins

Voices of Employees

A content production company was experiencing inefficiencies in its contract-related operations. Below are some specific comments from the field:

Content Producer's Voice.
- "Every time I sign a contract, I have to explain it in person, which makes it hard for me to focus on other creative tasks."
- "Negotiating contracts with performers takes a lot of time, which often delays the delivery schedule."
Voice of the Legal Team
- "I spend a lot of time drafting and reviewing contracts, which interferes with my other work."
- "We don't have enough storage space for paper contracts, and it's hard to find past contracts."
Contractor (Performer) Comments.
- "In-person contract explanations are not always scheduled and it takes a long time to get a contract signed."
- "It is burdensome to make multiple visits to sign or revise contracts."

Project Background and Objectives

As these problems accumulated, employee overtime increased and overall company efficiency declined. To improve the situation, a project was launched to systemize contract-related operations. The objectives are as follows:

Increase efficiency: Streamline the process of creating, reviewing, and storing contracts to reduce the burden on employees.
Time Reduction: Reduce the amount of time required to close a contract by reducing the number of in-person contract explanations.
Reduce Costs: Reduce storage space for paper contracts and lower administrative costs.

Step 1: Gather all interested parties

Selecting and Convening Stakeholders

Gather all stakeholders involved in the project. Specifically, convene the parties involved in the following roles:

Content Producer: Determine the content and decide what items are required in the contract.
Legal team: drafts contracts and performs legal checks.
IT Engineer: responsible for designing and developing the system.

Organize a workshop

The next step is to bring these experts together for a workshop. The purpose of the workshop is for each person to explain his or her work and to deepen mutual understanding.

Step 2: Discuss business processes one at a time

Identify current processes

Identify current business processes. Specific processes may include the following:

Content creator determines the content and decides what items are required in the contract (performance fee, duration of distribution, content of performance).
the legal team prepares a contract based on this information
the contractor reviews the contract and decides whether or not to sign it.
Legal team checks and keeps the signed contract.

Identifying Problems

Identify problems in the current process. For example:

Explaining and signing contracts in person takes time.
Space is needed for paper storage of contracts.
It is difficult to revise the contract if it is incomplete.

Step 3: Create an Entity and Interaction Diagram

Identifying Entities

Identify the key entities involved in the business process. The following entities are considered here:

Content: Information about the work or program to be produced.
Contract: A document that describes the fee for the performance and the duration of the distribution.
Performer: The person who is the subject of the contract.
Legal team: prepares and manages the contract.

Create an illustration of entouragement

Step 4: Identify bounded contexts

Identifying different concepts with the same name

If the term "contract" refers to both the legal team's working document and the final document that the performer signs, distinguish between them.

Defining Contexts

Define which context each entity belongs to. This makes it clear that entities with the same name have different roles. For example:

Step 5: Record the model as a living document

Recording the model

Record the model as a document based on the entity and interaction diagrams you have created. This model will serve as a living document of the system and will be continuously updated.

Examples of documents to be recorded

Ubiquitous Language Dictionary 2. 2.Entity Diagram 3. 3.Context map 4.
sequence diagram
- Specific examples:

Save to shared space

Save models to a shared space and make them accessible to the entire team. This allows you to work with the most up-to-date model at all times.

Step 6: Develop Budget and Schedule

Develop a budget

Develop a budget for system development. Factors to consider include:

Development Costs: IT engineer labor costs, software licensing costs, etc.
Hardware costs: server and cloud service costs.
Testing: Cost of building the testing environment and conducting the testing.

Schedule Development

Develop a schedule for the project. The plan is divided into the following phases:

Requirement Definition: Confirm business process and determine system requirements.
Design: System architecture design and modeling.
Development: System implementation.
Testing: Testing and modifying the system.
Release: Deployment and implementation of the system.

Step 7: Convert the model to a system

Transition to System Development

Actual development is performed based on the model you have created. Possible required functions include the following:

Content data registration and editing function: Content creators can register and edit content information.
Contract creation function: Legal team can automatically generate contracts.
Interface with e-signature service: Allows subscribers to sign contracts online.
Contract Alert Function: Notification when a contract is not completed.

Sequence diagram after system migration.

Testing and Deployment

Once development is complete, test and deploy the system to ensure there are no problems.

Summary

This article has described the specific steps in DDD before moving on to development; the essence of DDD is to understand the business process in depth and to systematically leverage the knowledge of experts to build a model. Through this process, we felt that we have the potential to design a system that is not just a technical solution, but one that fundamentally solves a business problem. I would like to continue learning to create more valuable software.

Domain Driven Design (DDD) Practice: Live Streaming App Example

ma2mori — Wed, 05 Jun 2024 23:29:38 +0000

Domain Driven Design (DDD) Practice: Live Streaming App Example

Introduction

In previous article, we learned the basic concepts of Domain Driven Design (DDD). In this article, we will introduce a concrete practical example using a “live-streaming application” as a subject.

Overview of a live-streaming application

A live-streaming app is a platform where users distribute content in real-time and other users watch it. It has the following features

Viewing users can also be delivery users
Viewers can provide feedback to the distributor in the form of free and paid reactions

Therefore, the main modeling considerations are

User management
Distribution Management
Reaction management

In practice, we will work with domain experts to work out the details.

Domain Modeling

First, we will define the main entities, value objects, aggregates, services, and repositories for the live distribution application.

Entity

User
- Attributes: user id, name, profile information, follower list.
distribution
- Attributes: distribution ID, distributor (user), start time, end time, viewer list

value object

Profile Information
- Attributes: age, gender, self, etc.
Comment
- Attributes: comment content, poster (user), time posted
Reaction
- Attributes: reaction type (free, paid), reaction content, reaction time

aggregation

Distribution Aggregate
- Aggregation of related entities (comments, reactions) around a delivery

Services

Distribution Management Service
- Start and end distribution, manage viewers, aggregate reactions.

repository

User Repository
- Retrieve and save user information.
Distribution Repository
- Retrieve and store distribution information

Use Cases

In this section, we will take a practical look at the elements of DDD through a simple use case of a live-streaming application. The following example is in PHP.

Use Case: Start and End of Delivery

Start distribution
- When a user starts a delivery, a new delivery entity is created.

<?php

class ProfileInfo {
    public function __construct(
        private int $age, private string $gender, private string $age, private string $gender
        private string $gender, private string $bio
        private string $bio
    ) {}

    // getter methods
}

class User {
    private array $followers; }

    public function __construct(
        private string $userId, private string $name, private string $followers
        private string $name, private
        private ProfileInfo $profileInfo, private
        array $followers = [] )
    ) {
        $this->followers = array_map(fn($follower) => new UserId($follower), $followers); }
    }

    // getter methods
}

class UserId {
    public function __construct(private string $id) {}

    public function __toString(): string {
        return $this->id; }
    }
}

class LiveStream {
    private DateTime $startTime;
    private ?DateTime $endTime; }
    private array $viewers; private

    public function __construct(
        private string $streamId, private
        private User $streamer
    ) {
        $this->startTime = new DateTime();
        $this->endTime = null;
        $this->viewers = []; }
    }

    public function endStream(): void {
        $this->endTime = new DateTime(); }
    }

    public function addViewer(User $viewer): void {
        $this->viewers[] = $viewer; }
    }

    // other methods...
}

End of delivery
- When the delivery is finished, the end time of the delivery entity is set and the required data is saved.

<?php

class LiveStreamRepository {
    private array $liveStreams = [];

    public function save(LiveStream $liveStream): void {
        $this->liveStreams[$liveStream->streamId] = $liveStream;
    }

    public function findById(string $streamId): ?LiveStream {
        return $this->liveStreams[$streamId] ? null;?
    }
}

class LiveStreamService {
    public function __construct(private LiveStreamRepository $repository) {}

    public function startStream(string $streamId, User $streamer): void {
        $liveStream = new LiveStream($streamId, $streamer);
        $this->repository->save($liveStream); }
    }

    public function endStream(string $streamId): void {
        $liveStream = $this->repository->findById($streamId);
        if ($liveStream) {
            $liveStream->endStream();
            $this->repository->save($liveStream); }
        }
    }
}

Use Case: Sending Reactions

Send Free Reactions
- This is a use case where a user sends a free reaction.

<?php

class Reaction {
    private DateTime $time;.

    public function __construct(
        private string $type, private string $content
        private string $type, private string $content
    ) {
        $this->time = new DateTime(); }
    }

    // getter methods
}

class LiveStream {
    private array $reactions = [];

    public function addReaction(Reaction $reaction): void {
        $this->reactions[] = $reaction; }
    }

    // other methods...
}

Sending a Paid Reaction
- Use case where a user sends a paid reaction.

<?php

class PaidReaction extends Reaction {
    public function __construct(
        string $content,.
        private float $amount
    ) {
        parent::__construct('paid', $content);
    }

    // getter methods
}

domain-model-diagram

Benefits of the DDD Approach

The benefits of this approach are as follows.

Clear separation of business logic.
- Centralizing the business logic in the domain model improves code readability and maintainability.
High level of abstraction.
- Abstraction of complex domains into concepts such as entities, value objects, services, and repositories simplifies and strengthens the design.
Ensures consistency.
- Ensures consistency throughout the system by guaranteeing data integrity within the boundaries of the aggregation.
Ease of Testing.
- Clearly defined domain model facilitates unit and integration testing.
Extensibility.
- Models can be easily extended and modified to meet changing business requirements.

Conclusion

This article introduced the basic concepts and practices of Domain Driven Design (DDD) using a live-streaming application as an example; using the DDD approach, you will be able to effectively manage complex business logic. I look forward to continuing to learn more in order to create more valuable software.

Introduction to Domain Driven Design (DDD) - Basic Concepts and Rudiments of Practice

ma2mori — Tue, 14 May 2024 03:31:27 +0000

1. Introduction

In this article, I will explain the basic concepts and initial practices of Domain-Driven Design (DDD) as an output of what I have learned. My interest in DDD was sparked by the following reasons:

The product I was responsible for adopted DDD.
I struggled due to a lack of domain knowledge.

2. Basic Concepts of DDD

DDD is a method of software development that centers around domain knowledge in design. Below are the key concepts.

2.1 Domain

The domain refers to the area that the system deals with. For example, in an e-commerce site, this includes products, purchase history, orders, etc.

2.2 Bounded Contexts

Bounded Contexts are concepts that divide a part of the domain into a cohesive unit. For example, in an e-commerce site, it might be possible to separate "inventory management" and "sales management" into different contexts. By dividing the context, different parts of the design can be made independent, improving the clarity of the code.

2.3 Main Patterns in DDD

Entity: An object that can be uniquely identified within the domain. For example, a "customer" on an e-commerce site is an entity identified by an ID.
ValueObject: Unlike entities, ValueObjects are not identified uniquely. They are immutable, and examples include addresses and prices.
Service: Objects that handle the business logic of the domain, operating across multiple entities or aggregates. Services are divided into two types:
- Domain Service: Provides business logic across multiple entities or aggregates, maintaining consistency of business rules within the domain. For example, an "Order Service" would handle business logic related to orders.
- Application Service: Coordinates the overall business processes of the system based on user use cases, working with domain services and repositories. For example, an "Order Processing Application Service" would manage the entire process related to orders (creation, confirmation, stock reservation, payment processing, shipping arrangements, etc.).
Repository: Objects responsible for storing and reconstructing data from entities or aggregates. For example, a "Customer Repository" stores customer entities and retrieves them when needed.
Factory: Specializes in creating objects, particularly useful when the creation process varies under certain conditions or the objects are complex. Using factories can hide the details of creation, enhancing code reusability and testability.
Aggregate: Groups entities and ValueObjects into a single unit that holds a set of operations and rules. For example, an "Order Aggregate" would include customer entities and product ValueObjects, providing operations related to orders.

These patterns can be categorized as follows:

Representing Knowledge
- Entity
- ValueObject
- Domain Service
- Aggregate
Realizing Applications
- Repository
- Application Service
- Factory

3. Practical Examples of DDD

Domain modeling is a design process that organizes business logic and implements business rules. First, the entire domain is divided into bounded contexts, and within each area, entities, ValueObjects, and relationships between entities are defined. This enhances the integrity and reusability of the system, efficiently applying specific business rules. Examples of domain modeling are shown below.

3.1 Customer Context Modeling

In the "Customer" context, a "Customer" entity and a "Name" ValueObject are defined. The customer entity includes attributes such as name, email address, and address, and the name ValueObject includes first and last name attributes.

3.2 Handling Price Fluctuations

On an e-commerce site, product prices can fluctuate due to sales and other promotions. By equipping the price ValueObject with attributes for "regular price" and "discount price," as well as "discount rate," it is possible to accurately manage prices during sales periods. The price change service implements price switches based on specific conditions (sale periods, promotions for certain customers, etc.).

3.3 Order Returns

To handle order returns, domain services and repositories are utilized to implement the return process. The order service adds a "return" function, defining the business logic for how to return products when returns occur. The following is an example of the return process:

Saving Return Reasons and Product Information The return request includes the reason for return and the information of the returned product (product name, price, quantity, etc.), which is stored in the repository. This allows tracking which products were returned for what reasons, aiding in later analysis and improvements.
Updating Inventory Returned products are restocked, and the inventory is updated as part of the return process. This ensures that the latest inventory information is maintained, and accurate stock levels are known across other orders and inventory management systems.
Notifying Customers After the return process is completed, customers are notified. Notifications include confirmation of return approval, receipt of returned

goods, and progress of the refund process, helping customers understand at what stage their return is.

4. Conclusion

Studying DDD has made me realize that it is possible to organize complex business logic and achieve high-reusability designs. The concept of bounded contexts, in particular, is very important for clearly segmenting the entire system and focusing on domain-centric design. While there is still much to learn in practice, this study has helped me re-recognize the importance of domain knowledge in system design. I intend to continue learning and utilize the concepts of DDD in future projects to create more valuable software.