Modular-Monolith on TECHFOR by Suriya Sonphu

การสร้าง Full Stack Web Application: Vue.js + Tailwind CSS + ASP.NET Core 9 Minimal API ด้วย Modular Monolith Architecture

Fri, 08 Aug 2025 00:00:00 +0000

บทนำ: Full Stack Development คืออะไร?

Full Stack Development หมายถึงการพัฒนาทั้งส่วน frontend (ฝั่งผู้ใช้) และ backend (ฝั่งเซิร์ฟเวอร์) ของเว็บแอปพลิเคชัน นักพัฒนา full stack คือผู้ที่สามารถทำงานได้ทั้งส่วนของ user interface ที่ผู้ใช้มองเห็นและโต้ตอบได้ และส่วนของ server logic ที่ทำงานเบื้องหลัง

องค์ประกอบหลักของ Full Stack Development:

Frontend (Client-side): สิ่งที่ผู้ใช้เห็นและโต้ตอบ
- User Interface (UI)
- User Experience (UX)
- Client-side logic และการทำงานโต้ตอบ
Backend (Server-side): เครื่องยนต์ที่ขับเคลื่อนแอปพลิเคชัน
- Server logic และ APIs
- การจัดการฐานข้อมูล
- Authentication และความปลอดภัย
- Business logic
Database: ที่เก็บและจัดการข้อมูล
DevOps: การ deploy และจัดการ infrastructure

ในบทความนี้ เราจะสร้าง full stack application ที่สมบูรณ์โดยใช้เทคโนโลยีสมัยใหม่: Vue.js สำหรับ frontend, Tailwind CSS สำหรับการจัดแต่งหน้าตา และ ASP.NET Core 9 Minimal API สำหรับ backend โดยจัดระบบด้วย Modular Monolith architecture

Vue.js คืออะไร?

Vue.js เป็น progressive JavaScript framework สำหรับสร้าง user interfaces และ single-page applications (SPAs) สร้างโดย Evan You ในปี 2014 Vue.js ได้กลายเป็นหนึ่งใน frontend frameworks ที่ได้รับความนิยมมากที่สุด เคียงข้างกับ React และ Angular

คุณสมบัติหลักของ Vue.js:

Progressive Framework: สามารถใช้ Vue.js แบบค่อยเป็นค่อยไป - ใช้เพียงส่วนหนึ่งของหน้าเว็บหรือสร้างแอปพลิเคชันทั้งหมด
Reactive Data Binding: UI อัปเดตอัตโนมัติเมื่อข้อมูลเปลี่ยน
Component-Based Architecture: สร้าง components ที่ห่อหุ้มและจัดการ state ของตัวเอง
Virtual DOM: การ render ที่มีประสิทธิภาพสำหรับความเร็วที่เหมาะสม
ง่ายต่อการเรียนรู้: syntax ที่เรียบง่าย เข้าใจง่ายสำหรับผู้เริ่มต้น

ข้อดีของ Vue.js:

ขนาด bundle เล็ก: โหลดเร็ว
เอกสารที่เยี่ยม: ครอบคลุมและเข้าใจง่ายสำหรับผู้เริ่มต้น
ระบบนิเวศที่ดี: เครื่องมือและไลบรารีที่หลากหลาย
รองรับ TypeScript: การผสานรวม TypeScript อย่างเต็มรูปแบบ
Composition API: วิธีสมัยใหม่ในการจัดระเบียบ component logic

ตัวอย่าง Vue.js Component:

<template>
 <div class="user-profile">
 <h2>{{ user.name }}</h2>
 <p>{{ user.email }}</p>
 <button @click="updateProfile">อัปเดตโปรไฟล์</button>
 </div>
</template>

<script setup>
import { ref, reactive } from 'vue'

const user = reactive({
 name: 'สมชาย ใจดี',
 email: 'somchai@example.com'
})

const updateProfile = () => {
 // อัปเดตโปรไฟล์ผู้ใช้
 console.log('โปรไฟล์ถูกอัปเดตแล้ว!')
}
</script>

อ้างอิง: Vue.js Official Documentation

Tailwind CSS คืออะไร?

Tailwind CSS เป็น utility-first CSS framework ที่ให้ utility classes ระดับต่ำสำหรับสร้างการออกแบบที่กำหนดเองได้โดยตรงใน markup แทนที่จะเขียน custom CSS คุณจะประกอบการออกแบบด้วยการรวม utility classes ขนาดเล็กที่มีจุดประสงค์เดียว

คุณสมบัติหลักของ Tailwind CSS:

Utility-First: classes ที่สร้างมาล่วงหน้าสำหรับ CSS properties ทั่วไป
Responsive Design: utilities สำหรับ responsive design ที่สร้างไว้แล้ว
ปรับแต่งได้: ระบบการออกแบบที่กำหนดค่าได้สูง
ประสิทธิภาพ: ลบ CSS ที่ไม่ใช้อัตโนมัติ
ประสบการณ์นักพัฒนา: รองรับ IDE และเครื่องมือ debugging ที่เยี่ยม

ข้อดีของ Tailwind CSS:

การพัฒนาอย่างรวดเร็ว: สร้าง interfaces ได้เร็วโดยไม่ต้องเขียน custom CSS
การออกแบบที่สอดคล้อง: ระบบการออกแบบที่สร้างไว้แล้วรับประกันความสอดคล้อง
Mobile-First: responsive design ตั้งแต่ต้น
ขนาด Bundle เล็ก: รวมเฉพาะ CSS ที่คุณใช้จริง
ไม่ต้องเปลี่ยนบริบท: จัดแต่ง components โดยไม่ต้องออกจาก HTML

ตัวอย่างการใช้ Tailwind CSS:

<!-- วิธี CSS แบบดั้งเดิม -->
<div class="card">
 <h2 class="card-title">สวัสดีครับ</h2>
 <p class="card-description">นี่คือคำอธิบาย</p>
 <button class="btn btn-primary">คลิกที่นี่</button>
</div>

<!-- วิธี Tailwind CSS -->
<div class="bg-white p-6 rounded-lg shadow-md">
 <h2 class="text-2xl font-bold text-gray-900 mb-2">สวัสดีครับ</h2>
 <p class="text-gray-600 mb-4">นี่คือคำอธิบาย</p>
 <button class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded">
 คลิกที่นี่
 </button>
</div>

Tailwind CSS Classes ที่ใช้บ่อย:

Layout: flex, grid, container, mx-auto
Spacing: p-4 (padding), m-2 (margin), space-y-4
Typography: text-xl, font-bold, text-center
Colors: bg-blue-500, text-red-600, border-gray-300
Responsive: sm:text-lg, md:grid-cols-2, lg:px-8

อ้างอิง: Tailwind CSS Official Documentation

ASP.NET Core 9 Minimal API คืออะไร?

ASP.NET Core Minimal API เป็นแนวทางที่เรียบง่ายในการสร้าง HTTP APIs ด้วย ASP.NET Core เปิดตัวใน .NET 6 และปรับปรุงในเวอร์ชันต่อๆ มารวมถึง .NET 9 Minimal APIs ช่วยให้คุณสร้าง APIs ได้โดยใช้ code น้อยและไม่ซับซ้อน

คุณสมบัติหลักของ Minimal API:

Boilerplate น้อย: เขียน code น้อยกว่าแบบ controllers ดั้งเดิม
ประสิทธิภาพ: ประสิทธิภาพสูงด้วย overhead ที่น้อย
Syntax เรียบง่าย: เข้าใจและเขียนง่าย
คุณสมบัติที่สร้างไว้: model binding, validation และรองรับ OpenAPI อัตโนมัติ
Hosting: ผสานรวมกับ ASP.NET Core hosting model

ข้อดีของ Minimal API:

การพัฒนาอย่างรวดเร็ว: สร้าง APIs ได้เร็วด้วยการตั้งค่าที่น้อย
เหมาะกับ Microservices: เหมาะสำหรับ services ขนาดเล็กที่มีจุดมุ่งหมายเฉพาะ
Cloud Native: เหมาะสำหรับสภาพแวดล้อม containerized
คุณสมบัติ C# สมัยใหม่: ใช้ประโยชน์จากคุณสมบัติล่าสุดของภาษา C#
การผสานรวม: ทำงานร่วมกับไลบรารี .NET อื่นๆ ได้อย่างราบรื่น

ตัวอย่าง Minimal API:

using Microsoft.EntityFrameworkCore;

var builder = WebApplication.CreateBuilder(args);

// เพิ่ม services ลงใน container
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlite("DataSource=app.db"));

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

var app = builder.Build();

// กำหนดค่า HTTP request pipeline
if (app.Environment.IsDevelopment())
{
 app.UseSwagger();
 app.UseSwaggerUI();
}

app.UseHttpsRedirection();

// กำหนด API endpoints
app.MapGet("/api/products", async (AppDbContext db) =>
 await db.Products.ToListAsync())
 .WithName("GetProducts")
 .WithOpenApi();

app.MapGet("/api/products/{id}", async (int id, AppDbContext db) =>
 await db.Products.FindAsync(id) is Product product
 ? Results.Ok(product)
 : Results.NotFound())
 .WithName("GetProduct")
 .WithOpenApi();

app.MapPost("/api/products", async (Product product, AppDbContext db) =>
{
 db.Products.Add(product);
 await db.SaveChangesAsync();
 return Results.Created($"/api/products/{product.Id}", product);
})
.WithName("CreateProduct")
.WithOpenApi();

app.Run();

// Models
public class Product
{
 public int Id { get; set; }
 public string Name { get; set; } = string.Empty;
 public decimal Price { get; set; }
 public string Description { get; set; } = string.Empty;
}

public class AppDbContext : DbContext
{
 public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
 public DbSet<Product> Products { get; set; }
}

อ้างอิง: ASP.NET Core Minimal APIs Documentation

ตัวอย่างโปรเจค: E-commerce Product Catalog

มาสร้าง e-commerce product catalog อย่างง่ายที่แสดงให้เห็นว่าเทคโนโลยีทั้งหมดนี้ทำงานร่วมกันอย่างไรใน modular monolith architecture

โครงสร้างโปรเจค:

ECommerceApp/
├── frontend/ # Vue.js + Tailwind CSS
│ ├── src/
│ │ ├── components/
│ │ ├── views/
│ │ ├── services/
│ │ └── main.js
│ ├── index.html
│ └── package.json
├── backend/ # ASP.NET Core 9 Minimal API
│ ├── Modules/
│ │ ├── Products/
│ │ ├── Orders/
│ │ └── Users/
│ ├── Shared/
│ │ ├── Database/
│ │ └── Infrastructure/
│ ├── Program.cs
│ └── ECommerceApp.csproj
└── README.md

การติดตั้ง Frontend (Vue.js + Tailwind):

ProductList.vue:

<template>
 <div class="container mx-auto px-4 py-8">
 <h1 class="text-3xl font-bold text-gray-900 mb-8">แคตตาล็อกสินค้า</h1>

 <div class="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-3 gap-6">
 <div
 v-for="product in products"
 :key="product.id"
 class="bg-white rounded-lg shadow-md overflow-hidden hover:shadow-lg transition-shadow"
 >
 <div class="p-6">
 <h3 class="text-xl font-semibold text-gray-900 mb-2">
 {{ product.name }}
 </h3>
 <p class="text-gray-600 mb-4">{{ product.description }}</p>
 <div class="flex justify-between items-center">
 <span class="text-2xl font-bold text-blue-600">
 ฿{{ product.price }}
 </span>
 <button
 @click="addToCart(product)"
 class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
 >
 เพิ่มลงตะกร้า
 </button>
 </div>
 </div>
 </div>
 </div>
 </div>
</template>

<script setup>
import { ref, onMounted } from 'vue'
import { productService } from '../services/productService'

const products = ref([])

const fetchProducts = async () => {
 try {
 const response = await productService.getAll()
 products.value = response.data
 } catch (error) {
 console.error('เกิดข้อผิดพลาดในการดึงข้อมูลสินค้า:', error)
 }
}

const addToCart = (product) => {
 // เพิ่มลงตะกร้า logic
 console.log('เพิ่มลงตะกร้า:', product)
}

onMounted(() => {
 fetchProducts()
})
</script>

Product Service:

// services/productService.js
import axios from 'axios'

const API_BASE_URL = 'https://localhost:7070/api'

export const productService = {
 async getAll() {
 return await axios.get(`${API_BASE_URL}/products`)
 },

 async getById(id) {
 return await axios.get(`${API_BASE_URL}/products/${id}`)
 },

 async create(product) {
 return await axios.post(`${API_BASE_URL}/products`, product)
 }
}

การติดตั้ง Backend (ASP.NET Core 9 Minimal API):

Program.cs:

using Microsoft.EntityFrameworkCore;
using ECommerceApp.Modules.Products;
using ECommerceApp.Modules.Orders;
using ECommerceApp.Shared.Database;

var builder = WebApplication.CreateBuilder(args);

// เพิ่ม services ลงใน container
builder.Services.AddDbContext<AppDbContext>(options =>
 options.UseSqlite(builder.Configuration.GetConnectionString("DefaultConnection")));

// เพิ่ม CORS
builder.Services.AddCors(options =>
{
 options.AddPolicy("AllowFrontend", policy =>
 {
 policy.WithOrigins("http://localhost:3000")
 .AllowAnyHeader()
 .AllowAnyMethod();
 });
});

builder.Services.AddEndpointsApiExplorer();
builder.Services.AddSwaggerGen();

// ลงทะเบียน module services
builder.Services.AddProductModule();
builder.Services.AddOrderModule();

var app = builder.Build();

// กำหนดค่า HTTP request pipeline
if (app.Environment.IsDevelopment())
{
 app.UseSwagger();
 app.UseSwaggerUI();
}

app.UseHttpsRedirection();
app.UseCors("AllowFrontend");

// แมป module endpoints
app.MapProductEndpoints();
app.MapOrderEndpoints();

app.Run();

Product Module:

// Modules/Products/ProductModule.cs
using Microsoft.EntityFrameworkCore;
using ECommerceApp.Shared.Database;

namespace ECommerceApp.Modules.Products;

public static class ProductModule
{
 public static IServiceCollection AddProductModule(this IServiceCollection services)
 {
 services.AddScoped<IProductService, ProductService>();
 return services;
 }

 public static WebApplication MapProductEndpoints(this WebApplication app)
 {
 var group = app.MapGroup("/api/products").WithTags("Products");

 group.MapGet("/", GetProducts);
 group.MapGet("/{id}", GetProduct);
 group.MapPost("/", CreateProduct);
 group.MapPut("/{id}", UpdateProduct);
 group.MapDelete("/{id}", DeleteProduct);

 return app;
 }

 private static async Task<IResult> GetProducts(IProductService productService)
 {
 var products = await productService.GetAllAsync();
 return Results.Ok(products);
 }

 private static async Task<IResult> GetProduct(int id, IProductService productService)
 {
 var product = await productService.GetByIdAsync(id);
 return product != null ? Results.Ok(product) : Results.NotFound();
 }

 private static async Task<IResult> CreateProduct(Product product, IProductService productService)
 {
 var createdProduct = await productService.CreateAsync(product);
 return Results.Created($"/api/products/{createdProduct.Id}", createdProduct);
 }

 private static async Task<IResult> UpdateProduct(int id, Product product, IProductService productService)
 {
 if (id != product.Id) return Results.BadRequest();

 var updatedProduct = await productService.UpdateAsync(product);
 return updatedProduct != null ? Results.Ok(updatedProduct) : Results.NotFound();
 }

 private static async Task<IResult> DeleteProduct(int id, IProductService productService)
 {
 var success = await productService.DeleteAsync(id);
 return success ? Results.NoContent() : Results.NotFound();
 }
}

ทำไม Modular Monolith ถึงสำคัญ?

Modular Monolith รวมข้อดีของทั้ง monolithic และ microservices architectures ทำให้เป็นทางเลือกที่ยอดเยี่ยมสำหรับแอปพลิเคชันหลายประเภท โดยเฉพาะเมื่อเริ่มต้นโปรเจคใหม่

ข้อดีของ Modular Monolith:

ความเรียบง่าย: deployment unit เดียว ง่ายต่อการพัฒนาและ debug
ประสิทธิภาพ: ไม่มี network latency ระหว่าง modules
ความสอดคล้อง: database transactions เดียวข้าม modules
ความเร็วในการพัฒนา: การพัฒนาที่เร็วขึ้นด้วยการแชร์ code และไลบรารี
การปรับปรุงง่าย: สามารถแยกเป็น microservices ทีหลังได้หากจำเป็น

หลักการสำคัญ:

ขอบเขต Module ที่ชัดเจน: แต่ละ module มีความรับผิดชอบที่กำหนดไว้อย่างชัดเจน
การเชื่อมต่อแบบหลวม: modules สื่อสารผ่าน interfaces ที่กำหนดไว้อย่างดี
ความเหนียวแน่นสูง: functionality ที่เกี่ยวข้องอยู่ด้วยกันภายใน module
Infrastructure ร่วม: เรื่องทั่วไปเช่น logging, configuration, database

เมื่อไรควรใช้ Modular Monolith:

เริ่มโปรเจคใหม่: เริ่มด้วย monolith แล้วแยกทีหลังหากจำเป็น
ทีมขนาดเล็กถึงกลาง: การประสานงานและการพัฒนาที่ง่ายขึ้น
ขอบเขต domain ไม่แน่นอน: เรียนรู้ domain ก่อนแยก
ความต้องการประสิทธิภาพ: latency ต่ำกว่าระบบแบบกระจาย
ความต้องการความสอดคล้อง: ต้องการ ACID transactions ข้าม modules

ตัวอย่างโครงสร้าง Module:

// Modules/Products/
├── ProductModule.cs # การกำหนดค่า module และ endpoints
├── Models/
│ ├── Product.cs # Product entity
│ └── ProductDto.cs # Data transfer objects
├── Services/
│ ├── IProductService.cs # Service interface
│ └── ProductService.cs # Service implementation
└── Data/
 └── ProductRepository.cs # Data access layer

// Modules/Orders/
├── OrderModule.cs
├── Models/
├── Services/
└── Data/

// Shared/
├── Database/
│ └── AppDbContext.cs # Shared database context
├── Infrastructure/
│ ├── Logging/
│ └── Configuration/
└── Common/
 └── BaseEntity.cs # Shared base classes

เส้นทางการย้ายไป Microservices:

หากแอปพลิเคชันของคุณเติบโตและคุณต้องการแยกเป็น microservices โครงสร้างแบบ modular ทำให้การเปลี่ยนแปลงนี้ง่ายขึ้น:

ระบุขอบเขต Module: modules กลายเป็นขอบเขต service
แยกฐานข้อมูล: ให้แต่ละ service มีฐานข้อมูลของตัวเอง
เพิ่มชั้น Communication: แทนที่การเรียกตรงด้วย HTTP/messaging
Deploy อิสระ: แต่ละ service ได้ deployment pipeline ของตัวเอง

สรุป

การสร้าง full stack applications ด้วย Vue.js, Tailwind CSS และ ASP.NET Core 9 Minimal API โดยใช้ Modular Monolith architecture ให้:

ประสบการณ์การพัฒนาสมัยใหม่: เทคโนโลยีล่าสุดและแนวปฏิบัติที่ดีที่สุด
การพัฒนาอย่างรวดเร็ว: การทำซ้ำและ deployment ที่รวดเร็ว
สถาปัตยกรรมที่ขยายได้: สามารถเติบโตจาก monolith ไป microservices
ประสบการณ์นักพัฒนาที่ยอดเยี่ยม: เครื่องมือและเอกสารที่ยอดเยี่ยม
ประสิทธิภาพ: แอปพลิเคชันที่รวดเร็วและมีประสิทธิภาพ

วิธีการนี้เหมาะสำหรับผู้เริ่มต้นเขียนโปรแกรมเพราะให้:

การแยกส่วนงานที่ชัดเจน
แนวปฏิบัติการพัฒนาสมัยใหม่
สถาปัตยกรรมที่ขยายได้
แหล่งเรียนรู้ที่ยอดเยี่ยม

เริ่มต้นด้วย stack นี้ เรียนรู้พื้นฐาน และค่อยขยายความรู้ของคุณเมื่อแอปพลิเคชันมีความซับซ้อนมากขึ้น

อ้างอิง

Modular Monolith: สถาปัตยกรรมที่ผสมผสานข้อดีของ Monolith และ Microservices

Sun, 27 Jul 2025 00:00:00 +0000

Modular Monolith คืออะไร และทำไมถึงเป็นทางเลือกที่น่าสนใจ

Modular Monolith เป็นสถาปัตยกรรมซอฟต์แวร์ที่ผสมผสานข้อดีของ Monolith และ Microservices เข้าด้วยกัน โดยการจัดระเบียบโค้ดให้เป็นโมดูลที่มีขอบเขตชัดเจน (bounded context) แต่ยังคงการ deploy เป็นหน่วยเดียวกัน

ปัญหาของ Traditional Monolith

Traditional Monolith มักจะประสบปัญหา:

Tightly Coupled Code: โค้ดทุกส่วนผูกติดกันแน่น ยากต่อการแก้ไข
Single Point of Failure: หากส่วนใดส่วนหนึ่งเสีย ระบบทั้งหมดล้มเหลว
Technology Lock-in: ต้องใช้เทคโนโลยีเดียวกันทั้งแอปพลิเคชัน
Difficult to Scale: ไม่สามารถปรับขนาดแค่ส่วนที่ต้องการได้

ปัญหาของ Microservices

แม้ Microservices จะแก้ปัญหาหลายอย่างของ Monolith แต่ก็มีความซับซ้อนเพิ่มขึ้น:

Distributed System Complexity: ความซับซ้อนของระบบกระจาย
Network Latency: ความล่าช้าจากการสื่อสารผ่าน network
Data Consistency: ปัญหาความสอดคล้องของข้อมูล
Operational Overhead: ต้องการทีม DevOps ที่แข็งแกร่ง
Development Complexity: ความซับซ้อนในการพัฒนาและ debug

Modular Monolith: ทางออกที่สมดุล

Modular Monolith นำเสนอวิธีการที่สมดุล:

✅ ข้อดีที่ได้รับ:

Modularity: การแบ่งโมดูลที่ชัดเจนตาม business domain
Loose Coupling: โมดูลสื่อสารผ่าน interfaces ที่กำหนดไว้
Single Deployment: ง่ายต่อการ deploy และ maintain
Easier Testing: ทดสอบได้ง่ายกว่า distributed systems
Gradual Migration: สามารถแยกเป็น microservices ได้ในอนาคต

⚠️ ข้อควรพิจารณา:

Technology Constraint: ยังคงถูกจำกัดเทคโนโลยีหลัก
Shared Database: อาจมีปัญหา data coupling
Resource Scaling: ไม่สามารถ scale แต่ละโมดูลแยกได้

โครงสร้างของ Modular Monolith E-commerce Application

ผมได้สร้างตัวอย่าง Modular Monolith E-commerce Application ด้วย C# และ ASP.NET Core เพื่อแสดงให้เห็นการประยุกต์ใช้หลักการนี้ในการพัฒนาระบบจริง

🏗️ Architecture Overview

ECommerceApp/
├── src/
│ ├── ECommerceApp/ # Main Web API Application
│ │ ├── Controllers/ # API Controllers
│ │ ├── Program.cs # Application entry point
│ │ └── ECommerceApp.csproj
│ ├── ECommerceApp.Shared/ # Shared Kernel
│ │ ├── Events/ # Domain Events
│ │ ├── Kernel/ # Base entities, interfaces
│ │ └── ECommerceApp.Shared.csproj
│ └── Modules/
│ ├── Orders/ # Orders Module
│ │ ├── Application/ # Use cases, commands, queries
│ │ ├── Domain/ # Domain entities, events
│ │ ├── Infrastructure/ # Data access, repositories
│ │ ├── OrdersModule.cs # Module registration
│ │ └── ECommerceApp.Modules.Orders.csproj
│ ├── Products/ # Products Module
│ │ ├── Application/
│ │ ├── Domain/
│ │ ├── Infrastructure/
│ │ ├── ProductsModule.cs
│ │ └── ECommerceApp.Modules.Products.csproj
│ └── Customers/ # Customers Module
│ ├── Domain/
│ ├── Infrastructure/
│ ├── CustomersModule.cs
│ └── ECommerceApp.Modules.Customers.csproj

🎯 หลักการสำคัญของ Modular Monolith

1. Modules (โมดูล) แต่ละโมดูลแทนความสามารถทางธุรกิจที่แตกต่างกัน เช่น Orders, Products, Customers

2. Encapsulation (การห่อหุ้ม) โมดูลซ่อนรายละเอียดภายในและเปิดเผยเฉพาะ functionality ที่จำเป็นผ่าน interfaces

3. Shared Kernel (แกนร่วม) ส่วนที่ใช้ร่วมกัน เช่น base entities, common utilities, domain events

4. Communication (การสื่อสาร) โมดูลสื่อสารผ่าน interfaces หรือ domain events หลีกเลี่ยงการพึ่งพาโดยตรง

5. Single Deployment (การ Deploy เดียว) โมดูลทั้งหมดถูก deploy ร่วมกันเป็นหน่วยเดียว

การออกแบบโมดูลตาม Domain-Driven Design

Products Module

Domain Layer:

public class Product : BaseEntity
{
 public string Name { get; private set; }
 public string Description { get; private set; }
 public decimal Price { get; private set; }
 public int StockQuantity { get; private set; }

 public void UpdatePrice(decimal newPrice)
 {
 if (newPrice <= 0)
 throw new ArgumentException("Price must be positive");

 Price = newPrice;
 // Raise domain event
 RaiseDomainEvent(new ProductPriceUpdatedEvent(Id, newPrice));
 }

 public void UpdateStock(int quantity)
 {
 if (StockQuantity + quantity < 0)
 throw new InvalidOperationException("Insufficient stock");

 StockQuantity += quantity;
 RaiseDomainEvent(new ProductStockUpdatedEvent(Id, StockQuantity));
 }
}

Application Layer:

public class UpdateProductPriceCommand
{
 public Guid ProductId { get; set; }
 public decimal NewPrice { get; set; }
}

public class UpdateProductPriceHandler
{
 private readonly IProductRepository _repository;

 public async Task<Result> Handle(UpdateProductPriceCommand command)
 {
 var product = await _repository.GetByIdAsync(command.ProductId);
 if (product == null)
 return Result.Failure("Product not found");

 product.UpdatePrice(command.NewPrice);
 await _repository.UpdateAsync(product);

 return Result.Success();
 }
}

Orders Module

Domain Layer:

public class Order : BaseEntity
{
 public Guid CustomerId { get; private set; }
 public OrderStatus Status { get; private set; }
 public List<OrderItem> Items { get; private set; } = new();
 public decimal TotalAmount => Items.Sum(item => item.TotalPrice);

 public static Order Create(Guid customerId, List<OrderItem> items)
 {
 var order = new Order
 {
 CustomerId = customerId,
 Status = OrderStatus.Pending,
 Items = items
 };

 order.RaiseDomainEvent(new OrderCreatedEvent(order.Id, customerId));
 return order;
 }

 public void Confirm()
 {
 if (Status != OrderStatus.Pending)
 throw new InvalidOperationException("Only pending orders can be confirmed");

 Status = OrderStatus.Confirmed;
 RaiseDomainEvent(new OrderConfirmedEvent(Id));
 }
}

การสื่อสารระหว่างโมดูล

Interface-based Communication:

// ใน Orders Module
public interface IProductService
{
 Task<Product?> GetProductAsync(Guid productId);
 Task<bool> IsProductAvailableAsync(Guid productId, int quantity);
}

// ใน Products Module
public class ProductService : IProductService
{
 private readonly IProductRepository _repository;

 public async Task<Product?> GetProductAsync(Guid productId)
 {
 return await _repository.GetByIdAsync(productId);
 }

 public async Task<bool> IsProductAvailableAsync(Guid productId, int quantity)
 {
 var product = await _repository.GetByIdAsync(productId);
 return product != null && product.StockQuantity >= quantity;
 }
}

Event-based Communication (สำหรับอนาคต):

public class OrderConfirmedEvent : IDomainEvent
{
 public Guid OrderId { get; }
 public DateTime OccurredOn { get; }

 public OrderConfirmedEvent(Guid orderId)
 {
 OrderId = orderId;
 OccurredOn = DateTime.UtcNow;
 }
}

// Event Handler ใน Products Module
public class OrderConfirmedEventHandler : IEventHandler<OrderConfirmedEvent>
{
 public async Task Handle(OrderConfirmedEvent @event)
 {
 // Update inventory, send notifications, etc.
 }
}

การติดตั้งและรันแอปพลิเคชัน

Prerequisites

.NET 8.0 SDK
Visual Studio Code หรือ Visual Studio

การเริ่มต้นใช้งาน

1. Clone Repository:

git clone https://github.com/suriyasonp/modular-monolith-ecommerce.git
cd modular-monolith-ecommerce

2. รันแอปพลิเคชัน:

# วิธีที่ 1: ใช้ script (แนะนำ)
./run.sh

# วิธีที่ 2: รันด้วยตนเอง
dotnet build
dotnet run --project src/ECommerceApp/ECommerceApp.csproj

3. เข้าถึง API:

Swagger UI: http://localhost:5000/swagger/index.html
API Base URL: http://localhost:5000/api
Sample Products: ข้อมูลจะถูกสร้างอัตโนมัติเมื่อเริ่มระบบ

การทดสอบ API

Quick Test Script:

./test-api.sh

การทดสอบด้วยตนเอง:

# ดู Products ทั้งหมด
curl http://localhost:5000/api/products

# สร้าง Customer ใหม่
curl -X POST http://localhost:5000/api/customers \
 -H "Content-Type: application/json" \
 -d '{
 "firstName": "สมชาย",
 "lastName": "ใจดี",
 "email": "somchai@example.com",
 "address": {
 "street": "123 ถนนสุขุมวิท",
 "city": "กรุงเทพฯ",
 "state": "กทม",
 "zipCode": "10110",
 "country": "ไทย"
 }
 }'

# สร้าง Order ใหม่
curl -X POST http://localhost:5000/api/orders \
 -H "Content-Type: application/json" \
 -d '{
 "customerId": "customer-guid-here",
 "items": [
 {
 "productId": "product-guid-here",
 "quantity": 2
 }
 ]
 }'

API Endpoints ที่สำคัญ

Products API

GET /api/products - ดูสินค้าทั้งหมด
GET /api/products/{id} - ดูสินค้าตาม ID
POST /api/products - เพิ่มสินค้าใหม่
PUT /api/products/{id}/price - อัปเดตราคาสินค้า
PUT /api/products/{id}/stock - อัปเดตสต็อกสินค้า

Customers API

GET /api/customers - ดูลูกค้าทั้งหมด
GET /api/customers/{id} - ดูลูกค้าตาม ID
POST /api/customers - เพิ่มลูกค้าใหม่

Orders API

GET /api/orders - ดูออเดอร์ทั้งหมด
GET /api/orders/{id} - ดูออเดอร์ตาม ID
GET /api/orders/customer/{customerId} - ดูออเดอร์ของลูกค้า
POST /api/orders - สร้างออเดอร์ใหม่
POST /api/orders/{id}/confirm - ยืนยันออเดอร์
POST /api/orders/{id}/ship - จัดส่งออเดอร์
POST /api/orders/{id}/deliver - ส่งมอบออเดอร์

ข้อดีและข้อเสียของ Modular Monolith

✅ ข้อดี

1. ความเรียบง่ายในการ Deploy

Deploy เป็นหน่วยเดียว ลดความซับซ้อนของ infrastructure
ไม่ต้องกังวลเรื่อง service discovery หรือ load balancing
การ rollback ทำได้ง่าย

2. ประสิทธิภาพ

ไม่มี network latency ระหว่างโมดูล
การสื่อสารเป็น in-process calls
Transaction ข้าม modules ทำได้ง่าย

3. การพัฒนาและ Debug

Debug ได้ง่ายกว่า distributed systems
IDE support ดีกว่า
End-to-end testing ง่ายกว่า

4. ต้นทุนการดำเนินงาน

Infrastructure requirements ต่ำกว่า
ไม่ต้องมีทีม DevOps ขนาดใหญ่
Monitoring และ logging ง่ายกว่า

5. ความยืดหยุ่นในอนาคต

สามารถแยกเป็น microservices ได้เมื่อจำเป็น
โมดูลที่ออกแบบดีสามารถ extract ออกมาได้ง่าย

⚠️ ข้อเสีย

1. ข้อจำกัดด้านเทคโนโลยี

ต้องใช้เทคโนโลยีหลักเดียวกัน
ยากต่อการใช้ different tech stacks

2. การ Scale

ไม่สามารถ scale แต่ละโมดูลแยกได้
Resource utilization อาจไม่เหมาะสม

3. Database Coupling

หากใช้ shared database อาจมีปัญหา coupling
Schema migration ต้องระวังผลกระทบ

4. Team Independence

ทีมยังคงต้อง coordinate ใน deployment
Shared codebase อาจเป็นปัญหาในทีมใหญ่

เมื่อไหร่ควรใช้ Modular Monolith

🎯 เหมาะสำหรับ:

1. ทีมขนาดเล็กถึงกลาง (2-20 คน)

มีทรัพยากรจำกัดสำหรับ infrastructure complexity
ต้องการ development velocity สูง

2. แอปพลิเคชันใหม่

ยังไม่แน่ใจเรื่อง domain boundaries
ต้องการ rapid prototyping และ iteration

3. Requirements ยังไม่ชัดเจน

Business requirements เปลี่ยนแปลงบ่อย
ต้องการความยืดหยุ่นในการปรับเปลี่ยน

4. Limited DevOps Capability

ทีมยังไม่พร้อมสำหรับ distributed systems
Infrastructure automation ยังไม่เข้มแข็ง

🚫 ไม่เหมาะสำหรับ:

1. องค์กรขนาดใหญ่ที่มีทีมมาก

ทีมต้องการ independence สูง
มี different release cycles

2. Requirements ที่แตกต่างกันมาก

แต่ละส่วนมี scalability requirements ต่างกัน
ต้องการ different technologies

3. Compliance และ Security ข้อจำกัดสูง

ต้องการ isolation ระหว่าง components
มี regulatory requirements ที่เข้มงวด

การวางแผน Migration Path

Phase 1: เริ่มต้นด้วย Modular Monolith

Traditional Monolith → Modular Monolith

Activities:

ระบุ domain boundaries
สร้าง modules ตาม business capabilities
Implement interfaces สำหรับ inter-module communication
เพิ่ม domain events infrastructure

Phase 2: ปรับปรุง Module Independence

Tightly Coupled Modules → Loosely Coupled Modules

Activities:

แยก databases per module
ใช้ event-driven communication
Implement distributed tracing
เพิ่ม monitoring per module

Phase 3: Selective Microservices Extraction

Modular Monolith → Hybrid Architecture

Activities:

ระบุ modules ที่เหมาะสมสำหรับ extraction
Extract modules ที่มี different scaling needs
Implement API gateways
Setup service mesh

Best Practices สำหรับ Modular Monolith

🏗️ การออกแบบ Architecture

1. ใช้ Domain-Driven Design

// แยก bounded context ชัดเจน
namespace ECommerceApp.Modules.Orders.Domain
{
 public class Order { } // Order ใน Orders context
}

namespace ECommerceApp.Modules.Catalog.Domain
{
 public class Product { } // Product ใน Catalog context
}

2. Dependency Direction

// ❌ ผิด: High-level module พึ่งพา low-level
public class OrderService
{
 private SqlOrderRepository _repository; // Direct dependency
}

// ✅ ถูก: Dependency Inversion
public class OrderService
{
 private readonly IOrderRepository _repository; // Interface dependency
}

3. Module Registration

public static class ModuleExtensions
{
 public static IServiceCollection AddOrdersModule(this IServiceCollection services)
 {
 services.AddScoped<IOrderRepository, SqlOrderRepository>();
 services.AddScoped<OrderService>();
 services.AddMediatR(typeof(OrdersModule));
 return services;
 }
}

🔄 การจัดการ Communication

1. Synchronous Communication

// Interface-based communication สำหรับ immediate consistency
public interface IInventoryService
{
 Task<bool> IsAvailableAsync(Guid productId, int quantity);
 Task ReserveAsync(Guid productId, int quantity);
}

2. Asynchronous Communication

// Event-based communication สำหรับ eventual consistency
public class OrderConfirmedEvent : IDomainEvent
{
 public Guid OrderId { get; }
 public List<OrderItem> Items { get; }
}

[EventHandler]
public class UpdateInventoryHandler : IEventHandler<OrderConfirmedEvent>
{
 public async Task Handle(OrderConfirmedEvent @event)
 {
 // Update inventory asynchronously
 }
}

🗃️ การจัดการ Data

1. Shared Database with Schema Separation

-- Orders schema
CREATE SCHEMA Orders;
CREATE TABLE Orders.Orders (...);
CREATE TABLE Orders.OrderItems (...);

-- Products schema
CREATE SCHEMA Products;
CREATE TABLE Products.Products (...);
CREATE TABLE Products.Categories (...);

2. Database per Module (Advanced)

public class OrdersDbContext : DbContext
{
 protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
 {
 optionsBuilder.UseSqlServer(connectionString, options =>
 {
 options.MigrationsHistoryTable("__OrdersMigrationsHistory", "Orders");
 });
 }
}

🧪 การทดสอบ

1. Module Integration Tests

[Test]
public async Task CreateOrder_WithValidProducts_ShouldSucceed()
{
 // Arrange
 var productService = ServiceProvider.GetService<IProductService>();
 var orderService = ServiceProvider.GetService<IOrderService>();

 // Act
 var result = await orderService.CreateOrderAsync(customerId, orderItems);

 // Assert
 Assert.IsTrue(result.IsSuccess);
}

2. Contract Tests

[Test]
public void ProductService_ShouldImplementIProductService()
{
 // Verify that ProductService implements all required interfaces
 var productService = new ProductService();
 Assert.IsInstanceOf<IProductService>(productService);
}

Real-world Considerations

🔧 Production Enhancements

1. Database Integration

// Replace in-memory repositories with Entity Framework Core
services.AddDbContext<OrdersDbContext>(options =>
 options.UseSqlServer(connectionString));

services.AddScoped<IOrderRepository, EfOrderRepository>();

2. Authentication & Authorization

services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
 .AddJwtBearer(options => {
 options.TokenValidationParameters = new TokenValidationParameters
 {
 ValidateIssuer = true,
 ValidateAudience = true,
 ValidateLifetime = true,
 ValidateIssuerSigningKey = true
 };
 });

3. Input Validation

public class CreateOrderCommandValidator : AbstractValidator<CreateOrderCommand>
{
 public CreateOrderCommandValidator()
 {
 RuleFor(x => x.CustomerId).NotEmpty();
 RuleFor(x => x.Items).NotEmpty();
 RuleForEach(x => x.Items).SetValidator(new OrderItemValidator());
 }
}

4. Error Handling

public class GlobalExceptionMiddleware
{
 public async Task InvokeAsync(HttpContext context, RequestDelegate next)
 {
 try
 {
 await next(context);
 }
 catch (DomainException ex)
 {
 await HandleDomainExceptionAsync(context, ex);
 }
 catch (Exception ex)
 {
 await HandleGenericExceptionAsync(context, ex);
 }
 }
}

📊 Monitoring และ Observability

1. Health Checks

services.AddHealthChecks()
 .AddDbContextCheck<OrdersDbContext>("orders-db")
 .AddDbContextCheck<ProductsDbContext>("products-db")
 .AddUrlGroup(new Uri("https://external-api.com/health"), "external-api");

2. Logging

services.AddSerilog((context, config) =>
{
 config.ReadFrom.Configuration(context.Configuration)
 .Enrich.WithProperty("Module", "Orders")
 .WriteTo.Console()
 .WriteTo.File("logs/orders-.log", rollingInterval: RollingInterval.Day);
});

3. Metrics

public class OrderMetrics
{
 private static readonly Counter OrdersCreated = Metrics
 .CreateCounter("orders_created_total", "Total number of orders created");

 public void IncrementOrdersCreated() => OrdersCreated.Inc();
}

ข้อสรุป

Modular Monolith เป็นสถาปัตยกรรมที่เหมาะสมสำหรับองค์กรหลายประเภท โดยเฉพาะทีมที่ต้องการประโยชน์ของ modularity แต่ยังไม่พร้อมสำหรับความซับซ้อนของ microservices

🔑 Key Takeaways:

1. เริ่มต้นอย่างเรียบง่าย

ใช้ Modular Monolith เป็นจุดเริ่มต้น
Focus บน domain modeling และ clean boundaries
ปรับปรุงแบบค่อยเป็นค่อยไป

2. ออกแบบให้พร้อมสำหรับการเปลี่ยนแปลง

ใช้ interfaces สำหรับ inter-module communication
Implement domain events infrastructure
เตรียม monitoring และ observability

3. วางแผน Migration Path

ระบุ modules ที่อาจต้อง extract ในอนาคต
ออกแบบ data access patterns ที่รองรับการแยก
สร้าง culture ของ modular thinking

4. Focus บน Business Value

อย่าให้ technical complexity บดบัง business goals
ใช้สถาปัตยกรรมที่เหมาะสมกับทีมและ context
Remember: Architecture คือ means ไม่ใช่ end

🚀 Next Steps:

ศึกษาโค้ด: ดู repository เพื่อเข้าใจ implementation details
ทดลองเรียกใช้: รัน ./test-api.sh เพื่อดูฟีเจอร์ทั้งหมด
เพิ่มฟีเจอร์: ลองสร้างโมดูลใหม่ตามแพทเทิร์นที่กำหนด
นำไปใช้จริง: ปรับแต่งสำหรับ production environment

Modular Monolith ไม่ใช่ silver bullet แต่เป็นเครื่องมือที่มีประสิทธิภาพสำหรับการสร้างระบบที่ maintainable, scalable และ evolvable ในระยะยาว

แหล่งอ้างอิง

Modular Monolith E-commerce Repository - ตัวอย่างการ implement
Domain-Driven Design - Eric Evans
Modular Monoliths - Kamil Grzybek
Building Microservices - Sam Newman
Clean Architecture - Robert C. Martin
ASP.NET Core Documentation - Microsoft Docs
Monolith vs Microservices vs Modular Monoliths - Monolith vs Microservices vs Modular Monoliths