Series:
Bài 1: Bài này.
Bài 2: EventStorming: Lý thuyết
Bài 3: EventStorming: Áp dụng Big Picture (1)
Bài 4: EventStorming: Áp dụng Big Picture (2)
Bài 5: Thiết kế kiến trúc (1) - Decisions
Bài 6: Thiết kế kiến trúc (2) - Sơ đồ tĩnh, động, và triển khai
---------------------------------------------------------
Mục tiêu
Ngày nay, thứ gì cũng cần nhanh. Trải nghiệm internet cần nhanh thể hiện ở báo giấy đã dần biến mất theo thời gian, báo điện tử cũng giảm dần lượng đọc. Mọi người có xu hướng nghe, nhìn để nắm được thông tin thay vì đọc. Khi giải trí, chúng ta có xu hướng xem video ngắn trên Tiktok hay Facebook Reels để tìm kiếm sự thoả mãn nhanh chóng. Bạn hãy thử ngẫm lại xem gần nhất mình đã hoàn thành đọc hay nghiên cứu một quyển sách kỹ thuật một cách tường tận là khi nào? Tôi đã thấy, đã gặp khá nhiều bạn làm về phần mềm (tất nhiên, tôi chỉ biết về phần mềm) chỉ tham khảo tutorials mà bỏ quên hoặc không có khái niệm đọc sách. Ngày nay, khi AI đang là xu hướng và chúng ta đang dựa vào chúng để nâng cao hiệu suất phát triển. Đừng lo AI cướp mất công việc của mình nếu bạn vẫn giữ thói quen đọc sách, nghiên cứu sâu một hay một số lĩnh vực. Hãy kết hợp sách và tutorials và cả AI cho công việc và lộ trình học tập của mình. Sách là sự đúc kết kinh nghiệm chuẩn chỉ của những chuyên gia hàng đầu. Một quyển sách không phải được viết một lèo cho xong giống như ta viết một bài văn, đó là cả một dự án với tâm điểm là kiến thức vững chắc của một hoặc một nhóm người. Đọc một quyển sách giúp ta tiến bộ thêm 5 năm, giúp ta hàng ngày mở mang được tầm mắt để nhìn ra thế giới rộng mở, giúp ta biết được ta luôn cần phải học. Nghe có vẻ sách là tĩnh vì dự án dài quá nhưng thật ra phần mềm với những triết lý thiết kế có thời gian sống được tính bằng hàng chục năm. Bạn có thể kết hợp tutorials để xem nhanh những gì đang là xu hướng. Giờ đây, AI giúp ta học tập nhanh hơn nhưng bạn hãy luôn là người chủ động điều phối các cuộc trò chuyện với chúng để tránh những "ảo giác AI" mà chúng tạo ra. Trong quá trình sử dụng AI tôi thấy rằng, nếu ta không có đủ kiến thức ta sẽ chỉ khai thác được phần nông kiến thức rộng lớn của nó và ta dễ bị đưa vào "ảo giác". Do đó, hãy cứ yên tâm rằng bạn vẫn luôn giữ tinh thần học tập thì bạn vẫn có chỗ đứng trong thế giới đầy biến động này.
Để phục vụ mục tiêu tiếp cận nhanh chóng, hiệu quả các kỹ thuật cần có trong quy trình quy trình phân tích, thiết kế, phát triển các hệ thống phần mềm theo phương pháp Domain-Driven Design (DDD) và Microservices Architecture, tôi sẽ xây dựng một chuỗi bài viết hướng dẫn thực hành đan xen lý thuyết cơ bản. Chuỗi bài sẽ cố gắng bao phủ nhiều bước, có lẽ là những bước nổi bật nhất, trong quy trình phát triển từ tiếp nhận yêu cầu, phân tích, thiết kế và lập trình.
Kịch bản sử dụng là một hệ thống e-commerce với yêu cầu chức năng cơ bản. Các chức năng nâng cao, đòi hỏi kỹ thuật nâng cao sẽ tiếp tục được bổ sung theo thời gian để làm nổi bật những chủ đề kỹ thuật phù hợp.
Mốc chính
Xây dựng một hệ thống microservices không chỉ là chia nhỏ hệ thống thành những phần nhỏ hơn gọi là service, đó còn là hành trình từ khám phá nghiệp vụ, phân tích thiết kế và đến triển khai sản phẩm. Tài liệu này sẽ đưa bạn qua quá trình phát triển một hệ thống e-commerce, từ giả định yêu cầu của merchant và khách hàng, đến thiết kế và triển khai các dịch vụ. Chúng ta sẽ sử dụng EventStorming để khám phá domain, thiết kế use case theo Clean Architecture, áp dụng DDD cũng như Hexagonal Architecture cho hệ thống.
Với demo end-to-end, bạn sẽ thấy cách các quy trình như Khởi tạo sản phẩm hay Đặt hàng trở thành hiện thực, sẵn sàng cho môi trường production.
Quy trình phát triển
Quy trình phát triển hệ thống phần mềm chia thành hai giai đoạn chính: Tổng thể và Chi tiết. Ở giai đoạn tổng thể, dự án được hình thành theo nhu cầu của PO, nhà đầu tư và sau đó, các bên lên quan (stakeholder) sẽ được hình thành. Kết quả đầu ra có thể là các use story chính, tài liệu thiết kế kiến trúc (Architectual Description – AD), tài liệu nghiệp vụ tổng quát BRD, product backlog kèm một lộ trình triển khai.
Kết quả này được đưa sang giai đoạn chi tiết để lên kế hoạch cho từng Sprint. Tại mỗi Sprint, tài liệu thiết kế chi tiết (Technical Detail Design – TDD) cùng tài liệu nghiệp vụ chi tiết được tạo ra. Các tài liệu này được áp dụng ở bước triển khai ngay sau đó.
Nghe có vẻ hơi giống mô hình Waterfall truyền thống, nhưng điểm khác biệt quan trọng nằm ở cách chúng ta vận hành: ở giai đoạn Tổng thể, các bước được tiến hành theo lối cuốn chiếu. Nghĩa là, bất cứ phần nào đã có kết quả sẽ được đẩy ngay sang giai đoạn Chi tiết để bắt đầu triển khai song song, thay vì chờ đợi toàn bộ giai đoạn Tổng thể hoàn tất.
Đặc biệt, trong quy trình phân tích của chúng ta, tôi đã áp dụng EventStorming – một kỹ thuật phân tích và thiết kế tương tác cao. EventStorming được thực hiện thông qua các buổi hội thảo sôi nổi giữa tất cả các bên liên quan, giúp chúng ta nâng cao hiệu quả và rút ngắn đáng kể thời gian phân tích so với các phương pháp truyền thống.
Các bước bao gồm:
User Story
Trong một nền tảng thương mại điện tử sôi động, trải nghiệm của merchant và customer là tâm điểm của mọi hoạt động kinh doanh. Từ việc merchant tạo sản phẩm mới để trưng bày trên gian hàng, bổ sung hàng vào kho, đến customer duyệt sản phẩm, đặt hàng, và chia sẻ đánh giá, mỗi tương tác đều đóng vai trò quan trọng trong việc tạo ra giá trị. Các user story, như "Tôi muốn tạo sản phẩm với mã SKU duy nhất" hay "Tôi muốn nhận thông báo khi tồn kho thấp", là tiếng nói của những nhu cầu thực tế, được product owner ghi nhận để định hình hệ thống. Bộ user story này, từ việc quản lý sản phẩm, tồn kho, đến xử lý đơn hàng và đánh giá sản phẩm, phác họa một bức tranh toàn diện về cách hệ thống vận hành, đảm bảo trải nghiệm mượt mà cho cả người bán và người mua.
Hãy cùng đi vào chi tiết các user story - là đề bài cho hệ thống của chúng ta.
Nhóm sản phẩm
Tạo sản phẩm
Mã: US-01.01
· Là một merchant,
Tôi muốn tạo sản phẩm mới với thông tin chi tiết (mã SKU, tên, đơn giá, mô tả, thuộc tính) và ngưỡng cảnh báo tồn kho thấp,
Để tôi có thể đưa sản phẩm lên bán trên nền tảng.
· Tiêu chí nghiệm thu:
o Hệ thống lưu sản phẩm với đầy đủ thông tin (SKU, tên, giá, ngưỡng tồn kho thấp).
o Mã SKU phải duy nhất trong toàn hệ thống; báo lỗi nếu SKU đã tồn tại.
o Kiểm tra trùng lặp dựa trên cặp (tên sản phẩm, ID Merchant, thuộc tính); báo lỗi nếu sản phẩm trùng.
o Sản phẩm được tạo với tồn kho bằng 0.
Đánh giá sản phẩm
Mã: US-01.02
· Là một customer,
Tôi muốn gửi đánh giá và bình luận cho sản phẩm,
Để tôi có thể chia sẻ ý kiến với người khác.
· Tiêu chí nghiệm thu:
o Hệ thống lưu đánh giá, bình luận, và thông tin khách hàng.
o Cập nhật số sao trung bình và số lượt đánh giá sản phẩm.
o Kiểm tra bình luận không chứ từ ngữ không chuẩn mực.
Nhóm tồn kho
Tạo phiếu nhập kho
Mã: US-02.01
· Là một merchant,
Tôi muốn tạo phiếu nhập kho cho sản phẩm với số lượng và thông tin kho,
Để tôi có thể bổ sung hàng tồn kho để bán.
· Tiêu chí nghiệm thu:
o Hệ thống lưu phiếu nhập kho với mã SKU, số lượng (> 0), ID kho, ngày nhập.
o Tăng tồn kho của sản phẩm theo số lượng trong phiếu.
Nhận thông báo tồn kho
Mã: US-02.02
· Là một merchant,
Tôi muốn nhận thông báo khi tồn kho sản phẩm giảm xuống dưới ngưỡng cảnh báo,
Để tôi có thể nhập thêm hàng kịp thời.
· Tiêu chí nghiệm thu:
o Hệ thống gửi thông báo (email/push) khi tồn kho đạt ngưỡng cảnh báo.
Nhóm mua hàng
Đặt hàng và thanh toán
Mã: US-03.01
· Là một customer,
Tôi muốn duyệt sản phẩm, thêm sản phẩm vào giỏ hàng, đặt hàng, và thực hiện thanh toán,
Để tôi có thể mua các sản phẩm mong muốn.
· Tiêu chí nghiệm thu:
o Hệ thống hiển thị danh sách sản phẩm với tên, giá, số sao, số lượng đã bán, và trạng thái tồn kho (ví dụ: “Còn hàng”, “Hết hàng”).
o Hệ thống xử lý thanh toán qua cổng thanh toán.
o Đơn hàng được tạo thành công sau khi thanh toán.