Mục đích
Tài liệu này mô tả một cách tổng quan và giải thích kiến trúc của hệ thống Akajob
Akajob là một hệ thống kết nối việc làm đang được sử dụng bởi gần 30.000 người dùng trong nội bộ doanh nghiệp, được sử dụng như một nơi trung gian để kết nối giữa người tuyển dụng và ứng viên
Tài liệu này sẽ cung cấp một cái nhìn tổng quan về kiến trúc phần mềm đang được áp dụng trong hệ thống Akajob, các usecase chính đang được sử dụng, các mô hình thiết kế,… Các cơ sở lý thuyết của kiến trúc hiện tại sẽ được đề cập trong tài liệu này nhằm giúp người đọc hiểu rõ hơn về hệ thống Ngoài ra, tài liệu cũng sẽ phân tích các ưu nhược điểm hiện có của hệ thống và đề xuất các phương án cải thiện.
Phạm vi
Do mô hình và số lượng service của hệ thống Akajob là tương đối lớn, tài liệu này sẽ tập trung phân tích kiến trúc tổng quan, các mẫu thiết kế đang áp dụng và đi sâu vào phân tích các dịch vụ chính của hệ thống bao gồm phân tích use case, luồng nghiệp vụ,…
Các thành viên thực hiện tài liệu này bao gồm:
Họ và tên Vai trò Công việc
Hoàng Việt Bách Trưởng nhóm - Xây dựng dàn ý tiểu luận
- Thực hiện vẽ, phân tích các usecase
- Thực hiện vẽ, phân tích các mẫu kiến trúc
Cao Minh Sơn Thành viên - Đánh giá mẫu kiến trúc theo các tiêu chí
Divide and conquer, Increase cohesion, Reduce coupling, …
- Đánh giá mã nguồn theo các tiêu chí Coupling, Cohesion, SOLID
Khái niệm, từ viết tắt
Báo cáo sử dụng các khái niệm, các từ viết tắt sau:
• QLDA – Quản lý dự án
• Request – Yêu cầu được gửi từ phía client
• Response – Phản hồi của hệ thống
• User - Người dùng hệ thống
Tổng quan
Các nội dung tiếp theo sẽ bao gồm việc miêu tả chi tiết hơn ý tưởng xây dựng, mục đích và các yêu cầu liên quan của hệ thống
Ngoài ra, các yêu cầu phi chức năng có thể tác động đến cấu trúc của hệ thống, ví dụ như yêu cầu về tính an toàn và bảo mật của hệ thống, các yêu cầu về khả năng chuyển đổi, tái sử dụng của các chức năng mà module cũng sẽ được đề cập đến Tiếp đến, các chức năng chính của hệ thống cũng sẽ được giới thiệu thông qua các use case và đặc tả chi tiết, luồng nghiệp vụ của chức năng đó,…Tiếp theo đó, tài liệu sẽ tiến hành phân tích chi tiết vào kiến trúc hệ thống sử dụng, lý do lựa chọn kiến trúc, phân tích ưu nhược điểm của kiến trúc hiện tại, đề xuất phương án khắc phục
Cuối cùng, sẽ mô tả chi tiết về các mẫu kiến trúc đã lựa chọn Bằng việc chọn một vài component chính để thiết kế chi tiết, sẽ giúp mọi người hiểu rõ hơn về biểu đồ giữa các lớp, biểu đồ triển khai; cũng như sự tương tác giữa các component như thế nào
2 Mục đích và các ràng buộc
Giới thiệu chung
Hiện nay trong các doanh nghiệp lớn, cụ thể là trong các doanh nghiệp công nghệ thông tin, số lượng đơn vị, phòng ban là rất nhiều, kèm theo đó là khối lượng công việc, các dự án mà các đơn vị, phòng ban đó phụ trách cũng rất lớn, khiến cho nguồn nhân lực hiện có của các đơn vị thường xuyên bị quá tải và cần bổ sung nhân lực gấp Tuy nhiên, việc tuyển dụng thêm nhân lực đôi khi mất quá nhiều thời gian, khiến cho dự án có thể bị chậm tiến độ, dẫn đến giảm uy tín của công ty Thêm vào đó, việc tuyển dụng thêm có thể có ích cho dự án trong một thời điểm nhất định, tuy nhiên khi dự án kết thúc, đơn vị sẽ bị dư thừa nhân lực
Ngoài ra, hiện nay, nhu cầu nhận thêm việc làm thêm của các nhân viên trong công ty là rất lớn, ngoài thời gian làm việc cho dự án chính, họ mong muốn được nhận thêm việc để kiếm thêm thu nhập
Hiểu được các nhu cầu đó, hệ thống Akajob ra đời, đóng vai trò như một cầu nối giúp các dự án cần tuyển dụng và các ứng viên có nhu cầu làm thêm có thể kết nối với nhau Người quản lý của các dự án sẽ đăng tải các công việc cần tuyển lên hệ thống, bao gồm các thông tin như ngân sách tuyển dụng, số lượng tuyển dụng, mô tả công việc, kỹ năng yêu cầu,… Các ứng viên cũng sẽ cần khai báo các thông tin lên hệ thống như các kỹ năng hiện có, chứng chỉ, khóa học đã đạt được,… Sau khi đôi bên đã cung cấp đủ thông tin, hệ thống sẽ tính toán và gợi ý cho đôi bên về các đối tượng phù hợp, sau đó dự án có thể thuê ứng viên và ngược lại, các ứng viên có thể ứng tuyển vào các dự án được gợi ý Sau khi hoàn thành tất cả, hoặc một phần công việc, quản lý dự án sẽ tiến hành đăng ký chi trả cho ứng viên Việc chi trả sẽ được thực hiện thông qua một bên thứ ba, từ đó số tiền quyết toán sẽ được cộng vào kỳ lương tiếp theo của ứng viên
Ngoài chức năng kết nối tuyển dụng, về sau, Akajob cũng đã được phát triển bổ sung các tính năng như theo dõi, quản lý tiến độ học tập của nhân viên, quản lý chứng chỉ, kết nối người học và người dạy,…
Các đối tượng chính sử dụng trong hệ thống bao gồm: nhân viên trong công ty, quản lý dự án, trưởng đơn vị, quản trị hệ thống
Các giá trị mà hệ thống Akajob mang lại:
- Tối ưu hóa nguồn lực của công ty, tận dụng ngay các ứng viên trong công ty để tuyển dụng
- Là cấu nối giúp dự án tuyển dụng và ứng viên tìm thấy nhau
- Tiết kiệm chi phí cho dự án, dự án không cần phải thuê dài hạn với một người mới trong thời gian dài
- Tạo cơ hội để nhân viên có thể kiếm thêm thu nhập
- Là một kênh để nhân viên quản lý các chứng chỉ, kỹ năng của bản thân
Các yêu cầu phi chức năng
Yêu cầu về hiệu năng
Về thời gian phản hồi:
- Thời gian tìm kiếm không vượt quá 1 giây
- Thời gian load page không vượt quá 2 giây
- Thời gian nhận phản hồi API không vượt quá 1 giây
Số lượng người dùng đồng thời:
- Hệ thống phải có khả năng chịu tải khi có 200 người dùng đồng thời nhưng vẫn đảm bảo yêu cầu về thời gian phản hồi như trên
Yêu cầu về tính sẵn sàng
- Đảm bảo người dùng có thể truy cập, sử dụng hệ thống một cách liên tục không bị gián đoạn
- Đảm bảo hệ thống có khả năng phát hiện, xử lý lỗi tự động
Yêu cầu về tính tích hợp
- Hệ thống phải đảm có thể dễ dàng tích hợp với các hệ thống khác, đảm bảo việc giao tiếp và chia sẻ dữ liệu một cách hiệu quá
Yêu cầu về bảo mật
- Người dùng hệ thống phải được xác thực và cấp quyền trước khi sử dụng, đảm bảo user không có quyền không thể truy cập các chức năng giới hạn
- Hệ thống có thể ngăn ngừa tấn công Cross site
- Hệ thống đảm bảo giới hạn dung lượng file tải lên
Yêu cầu về cơ sở dữ liệu
- Cơ sở dữ liệu phải có khả năng truy cập bất hợp pháp
- Cơ sở dữ liệu có cơ chế sao lưu – khôi phục
Yêu cầu về phân quyền
- Hệ thống phải đảm bảo các yêu cầu về xác thực theo quy định của công ty
- Hệ thống phải có cơ chế phân quyền đến các chức năng theo phạm vi sử dụng của từng đơn vị
Yêu cầu về giám sát, ghi nhật ký và cảnh báo
- Hệ thống phải cung cấp các dạng nhật ký để theo dõi, giám sát và dễ dàng truy vết các hoạt động của người dùng trên từng module như nhật ký truy cập để ghi nhận các request từ người dùng, nhật ký lỗi để ghi nhận các lỗi xảy ra trong hệ thống, nhật ký hệ thống để ghi nhận các thao tác, thời điểm và dữ liệu đã bị tác động vởi người dùng
- Hệ thống phải cung cấp cơ chế cảnh báo cho quản trị hệ thống nếu tài nguyên máy chủ đạt một ngưỡng nhất định hoặt khi hệ thống đang có số lượng người truy cập cao bất thường
Yêu cầu về sao lưu – khôi phục
- Hệ thống phải có các giải pháp sao lưu định kỳ
- Đảm bảo có thể khôi phục hệ thống
Như đã trình bày ở trên, do số lượng service của hệ thống tương đối lớn, nên trong tài liệu này nhóm xin phép tập trung vào phân tích các tác nhân của các service chính trong hệ thống Các tác nhân bao gồm: Ứng viên, Quản lý dự án (QLDA), Trưởng đơn vị và Admin. Trong đó, ứng viên là những nhân viên có nhu cầu tìm kiếm việc làm thêm
Quản lý dự án là người đứng đầu của dự án, phụ trách đăng tải các công việc lên hệ thống và tuyển dụng ứng viên.
Trưởng đơn vị là người đứng đầu đơn vị của Quản lý dự án Việc đăng tải công việc, tuyển dụng và chi trả đều phải có sự phê duyệt của Trưởng đơn vị
Admin là quản trị của toàn hệ thống, phụ trách cấu hình, phân quyền trên hệ thống.
Biểu đồ use case
Biểu đồ use case tổng quan
Với người dùng là ứng viên, hệ thống sẽ yêu cầu ứng viên khai báo các thông tin cá nhân ở lần đăng nhập đầu tiên Ứng viên sẽ phải khai báo các thông tin như bằng cấp, kỹ năng và mức độ của mỗi kỹ năng, chứng chỉ đã đạt được, các khóa học đã hoàn thành
Với đối tượng là QLDA, khi người dùng đăng tuyển dụng lên hệ thống sẽ phải nhập các thông tin như Ngân sách MM, số người cần tuyển, thời gian công việc, mô tả công việc, kỹ năng yêu cầu,… Sau khi được Trưởng đơn vị phê duyệt, QLDA mới có thể thuê ứng viên
Trưởng đơn vị là người có nhiệm vụ phê duyệt các yêu cầu như phê duyệt công việc, phê duyệt thuê ứng viên, phê duyệt chi trả cho ứng viên
Admin là quản trị hệ thống, có nhiệm vụ cấu hình các thông số của hệ thống cũng như phân quyền cho người dùng của hệ thống
Hình 1 : Biểu đồ usecase tổng quan các chức năng của Ứng viên, QLDA, Admin, Trưởng đơn vị
Biểu đồ use case phân rã
3.1.2.1 Phân rã use case “Các chức năng khai báo thông tin”
Hình 2 : Biểu đồ phân rã usecase “Các chức năng khai báo thông tin”3.1.2.2 Phân rã use case “Các chức năng liên quan tới tuyển dụng/chi trả”
Hình 3 Biểu đồ phân rã usecase “Các chức năng liên quan tới tuyển dụng/chi trả” 3.1.2.3 Phân rã use case “Các chức năng phê duyệt công việc”
Hình 4 Biểu đồ phân rã usecase “Các chức năng phê duyệt công việc”
3.2.2.1 Use case UC-01 “Đăng tuyển công việc” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA đăng đăng ký công việc b Tác nhân
Quản lý dự án c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền đăng ký công việc d Luồng sự kiện chính (đăng ký thành công)
- Bước 1: QLDA chọn chức năng “Tạo công việc”
- Bước 2: Hệ thống hiển thị giao diện Tạo công việc
- Bước 3: QLDA điền thông tin
- Bước 4: QLDA click vào nút Submit
- Bước 5: Hệ thống kiểm tra xem các trường bắt buộc đã được nhập hay chưa
- Bước 6: Hệ thống kiểm tra xem các trường đã nhập có hợp lệ hay không
- Bước 7: Hệ thống hiển thị Popup hỏi QLDA có muốn gửi mail cho các ứng viên tiềm năng hay không
- Bước 9: Hệ thống lưu thông tin công việc vào hệ thống và gửi mail cho các ứng viên tiềm năng
- Bước 10: Hệ thống redirect về trang chi tiết của công việc vừa tạo e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 5 Nếu QLDA nhập thiếu trường
Hệ thống báo lỗi cần nhập các trường yêu cầu
2 Bước 6 Nếu QLDA nhập thông tin không hợp lệ
Hệ thống báo lỗi thông tin không hợp lệ
Hệ thống lưu thông tin
CV nhưng không gửi mail cho các ứng viên
Bước 10 tiềm năng f Biểu đồ hoạt động
Hình 7 Biểu đồ hoạt động chức năng “Đăng tuyển công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Summary Tên công việc Có
2 Budgeted MM Quỹ MM Có
3 Project Code Mã dự án của công việc
4 Headcount Số người muốn thuê
5 Benefit Min Số tiền chi tối thiểu cho mỗi ứng viên
6 Benefit Max Số tiền chi tối đa cho mỗi ứng viên
7 Job title Tên vị trí cần tuyển
8 StartDate Ngày bắt đầu công việc
9 End Date Ngày kết thúc công việc
10 Contract Point Người liên hệ Có
13 Xjob purpose Mục đích thuê Có
15 Job description Mô tả công việc Có
16 Skills Kỹ năng yêu cầu Có
17 Level Level của kỹ năng
Có h Dữ liệu đầu ra
3.2.2.2 Đặc tả usecase UC 02 “Phê duyệt công việc”- a Giới thiệu
Usecase mô tả tương tác giữa Trưởng đơn vị và hệ thống khi Trưởng đơn vị phê duyệt công việc b Tác nhân
Trưởng đơn vị c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền Trưởng đơn vị
- QLDA đăng ký công việc trực thuộc phòng ban của Trưởng đơn vị d Luồng sự kiện chính (phê duyệt thành công)
- Bước 1: Trưởng đơn vị truy cập chi tiết công việc cần phê duyệt
- Bước 2: Hệ thống hiển thị màn hình chi tiết công việc
- Bước 3: Trưởng đơn vị click nút “Approve”
- Bước 4: Hệ thống hiển thị popup bao gồm các trường BudgetedMM (đang được hiển thị thông tin Budgeted MM mà QLDA đã nhập)
- Bước 5: Trưởng đơn vị chọn “Yes”
- Bước 6: Hệ thống kiểm tra xem trường bắt buộc đã được nhập chưa
- Bước 7: Hệ thống kiểm tra xem thông tin đầu vào có hợp lệ không
- Bước 8: Hệ thống cập nhật trạng thái cho công việc và gửi mail cho QLDA
- Bước 9: Hệ thống cập nhật lại màn chi tiết công việc e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu trưởng đơn vị click nút Reject và chọn Yes
Hệ thống hiện thị popup để nhập lý do từ chối và hai nút “Yes”, “Cancel”
Nếu chọn Yes, cập nhật trạng thái cho CV, gửi mail cho QLDA Cập nhật lại trang chi tiết
2 Bước 3 Nếu trưởng đơn vị click nút Reject và chọn
Nếu chọn Cancel, trở lại màn hình chi tiết CV
3 Bước 6 Nếu trưởng đơn vị xóa thông tin ở trường
Hệ thống báo lỗi cần nhập các trường yêu cầu
4 Bước 6 Nếu trưởng đơn vị chỉnh sửa thông tin
Bugeted MM và ấn yes
Hệ thống lưu cập nhật
CV với Budgeted MM mà Trưởng đơn vị vừa chỉnh sửa, gửi mail cho QLDA
Bước 9 f Biểu đồ hoạt động
Hình 8 Biểu đồ hoạt động chức năng “Phê duyệt công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Budgeted MM Quỹ MM h Dữ liệu đầu ra
3.2.2.3 Đặc tả usecase UC-03 “Ứng tuyển công việc” a Giới thiệu
Usecase mô tả tương tác giữa Ứng viên và hệ thống khi Ứng viên ứng tuyển vào công việc b Tác nhân Ứng viên c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt d Luồng sự kiện chính (ứng tuyển thành công)
- Bước 1: Ứng viên truy cập công việc
- Bước 2: Hệ thống hiển thị chi tiết công việc
- Bước 3: Ứng viên click “Apply”
- Bước 4: Hệ thống hiện thị popup xác nhận, bao gồm trường “Lý do ứng tuyển” và 2 button
- Bước 5: Ứng viên điền thông tin và ấn “Submit”
- Bước 6: Hệ thống kiểm tra trường bắt buộc
- Bước 7: Hệ thống lưu thông tin ứng viên vào hệ thống, gửi mail cho QLDA e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 4 Nếu ứng viên chọn
Quay lại màn chi tiết công việc
2 Bước 5 Nếu ứng viên không điền lý do ứng tuyển
Hệ thống báo lỗi yêu cầu nhập trường bắt buộc
Bước 4 f Biểu đồ hoạt động
Hình 9 Biểu đồ hoạt động chức năng “Ứng tuyển công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Reason Lý do ứng tuyển
Có h Dữ liệu đầu ra
3.2.2.4 Đặc tả usecase UC-04 “Thuê ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA thuê ứng viên b Tác nhân
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt
- Ứng viên đã ứng tuyển vào công việc d Luồng sự kiện chính (thuê thành công)
- Bước 1: QLDA truy cập danh sách ứng viên
- Bước 2: Hệ thống hiển thị danh sách ứng viên
- Bước 3: QLDA click nút “Hire” với ứng viên tương ứng
- Bước 4: Hệ thống hiển thị popup điền thông tin thuê
- Bước 5: QLDA nhập thông tin và ấn “Hire”
- Bước 6: Hệ thống kiểm tra các trường bắt buộc
- Bước 7: Hệ thống kiểm tra dữ liệu đầu vào có hợp lệ không
- Bước 8: Hệ thống lưu thông tin ứng viên và gửi mail cho trưởng đơn vị
- Bước 9: Cập nhật lại màn danh sách ứng viên e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu QLDA click “Add candidate”
Hiển thị form giống ở bước 4 nhưng tại trường Account, QLDA sẽ nhập account của ứng viên muốn tuyển
2 Bước 6 Nếu QLDA không điền các trường bắt buộc
Hệ thống báo lỗi yêu cầu nhập trường bắt buộc
3 Bước 7 Nếu QLDA điền thông tin không hợp lệ bao gồm:
Hệ thống hiển thị lỗi thông tin không hợp lệ
Bước 4 viên không phù hợp của Công việc
- Ứng viên chưa hoàn thành ít nhất 90% công việc ở dự án chính của mình
- Tổng tiền thuê (bao gồm MM * giá mỗi MM) > số tiền tối đa ở mục chi tiết CV f Biểu đồ hoạt động
Hình 10 Biểu đồ hoạt động chức năng “Thuê ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Account Account ứng viên Có
2 Job Vị trí của ứng viên
3 From Ngày bắt đầu thuê Có
4 To Ngày kết thúc thuê Có
6 MM Số MM muốn thuê Có
7 Cost per MM Giá mỗi MM muốn thuê
Phạm vi công việc Có h Dữ liệu đầu ra
3.2.2.5 Đặc tả usecase UC-05 “Phê duyệt ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa Trưởng đơn vị và hệ thống khi Trưởng đơn vị thuê ứng viên b Tác nhân
Trưởng đơn vị c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền Trưởng đơn vị
- Công việc đã được trưởng đơn vị phê duyệt
- QLDA của công việc trực thuộc phòng ban của trưởng đơn vị
- Ứng viên đã được QLDA thuê d Luồng sự kiện chính (phê duyệt thành công)
- Bước 1: Trưởng đơn vị truy cập danh sách ứng viên chờ phê duyệt
- Bước 2: Hệ thống hiển thị danh sách ứng viên chờ phê duyệt
- Bước 3: Trưởng đơn vị click nút “Approve”
- Bước 4: Hệ thống hiển thị popup gồm các trường như số MM, giá mỗi MM và tổng số tiền Trường MM và giá mỗi MM có giá trị khởi tạo là giá trị là QLDA đã nhập, các trường này có thể sửa được
- Bước 5: Trưởng đơn vị click nút “Agree”
- Bước 6: Hệ thống kiểm tra các trường bắt buộc
- Bước 7: Hệ thống kiểm tra tính hợp lệ của dữ liệu đầu vào
- Bước 8: Hệ thống cập nhật trạng thái và các thông tin sửa đổi nếu có cho ứng viên, gửi mail cho QLDA và ứng viên e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu Trưởng đơn vị click “Reject”, sau đó chọn Yes
Hiển thị form yêu cầu nhập lý do từ chối Nếu chọn Yes, hệ thống validate trường bắt buộc
Hệ thống cập nhật thông tin của ứng viên
2 Bước 3 Nếu Trưởng đơn vị click “Reject”, sau đó chọn No Đóng popup, trở lại màn hình trước đó
3 Bước 6 Nếu các trường bắt buộc không được nhập
Hệ thống báo lỗi yêu cầu nhập các trưởng bắt buốc
4 Bước 7 Nếu Trưởng đơn vị sửa đổi số MM và giá mỗi
Hệ thống kiểm tra xem thông tin nhập có hợp lệ không, báo lỗi trong các trường hợp sau:
- Nếu số MM lớn hơn số Budgeted
- Tổng giá lớn hơn tổng số tiền chi tối đa ở trong phần thông tin công việc
Bước 4 f Biểu đồ hoạt động
Hình 11 Biểu đồ hoạt động chức năng “Phê duyệt ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 MM Số MM đồng ý duyệt
2 Cost per MM Giá mỗi MM đồng ý duyệt h Dữ liệu đầu ra
3.2.2.6 Đặc tả usecase UC 06 “- Chi trả ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA chi trả cho ứng viên b Tác nhân
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt
- Ứng viên đã được đồng ý phê duyệt bởi Trưởng đơn vị d Luồng sự kiện chính (chi trả thành công)
- Bước 1: QLDA truy cập chi tiết công việc
- Bước 2: Hệ thống hiển thị chi tiết công việc
- Bước 3: QLDA chọn tab “Manage your candidates”
- Bước 4: Hệ thống hiển thị danh sách ứng viên
- Bước 5: QLDA click nút “Payment”
- Bước 6: Hệ thống hiển thị popup hiển thị thông tin các payment đã được tạo cho ứng viên đó
- Bước 7: QLDA click “New Payment”
- Bước 8: Hệ thống hiển thị popup để QLDA nhập số MM muốn chi trả
- Bước 7: QLDA điền số MM muốn chi trả, click “Submit”
- Bước 9: Hệ thống kiểm tra các trường bắt buộc
- Bước 10: Hệ thống kiểm tra thông tin nhập vào có hợp lệ không
- Bước 11: Hệ thống tạo yêu cầu chi trả thành công, gửi mail cho trưởng đơn vị e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 9 Nếu QLDA không nhập số MM
Hệ thống báo lỗi, yêu cầu nhập các trường bắt buộc
2 Bước 10 Nếu QLDA nhập số
Hệ thống kiểm tra nếu QLDA nhập số MM chi trả lớn hơn số MM còn lại của ứng viên, báo lỗi thông tin không hợp lệ
Bước 8 f Biểu đồ hoạt động
Hình 12 Biểu đồ hoạt động chức năng “Chi trả ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 MM Số MM muốn chi trả h Dữ liệu đầu ra
Dựa trên các yêu cầu nghiệp vụ ban đầu, hệ thống cần phải thỏa mãn các tiêu chí sau:
- Là một hệ thống website đa tác vụ, trong đó mỗi tác vụ có một nhiệm vụ riêng nhưng vẫn sẽ có những sự liên kết ở mức thấp
- Hệ thống có thể tích hợp được với nhiều bên khác bao gồm các hệ thống nội bộ của công ty, các hệ thống đào tạo trực tuyến như Udemy, Udacity,…
- Có thể dễ dàng mở rộng các tính năng mới trong tương lai
- Có thể xây dựng ứng dụng mobile trong tương lai
- Có sử dụng hệ thống Elasticsearch và phải đảm bảo tốc độ phản hồi nhanh (cụ thể là dưới 1s)
Dựa trên yêu cầu trên, hai mô hình kiến trúc đã được sử dụng kết hợp đó là Client-Server và Microservice
Hình 13 Ý tưởng kiến trúc sử dụng
Thứ nhất, có thể thấy các tác vụ nêu trên là các tác vụ riêng biệt, việc sử dụng Microservice sẽ đảm bảo các tác vụ trên có thể hoạt động một cách độc lập, không bị phụ thuộc lẫn nhau Ngoài ra, hệ thống Akajob cũng là một kênh trung gian để giao tiếp giữa các hệ thống khác trong nội bộ công ty và ngoài công ty, hay nói cách khác là hệ thống sẽ cần tích hợp, tương tác thường xuyên với các hệ thống khác Việc dễ dàng mở rộng các tính năng độc lập mới trong tương lai cũng sẽ rất thuận lợi khi quá trình phát triển, triển khai tính năng mới sẽ không làm ảnh hưởng đến các chức năng đang hoạt động Thêm vào đó, với việc yêu cầu sử dụng Elasticsearch, mô hình Microservice tỏ ra vượt trội khi mỗi service có thể sử dụng một công nghệ riêng, một cơ sở dữ liệu riêng, chỉ các service cần sử dụng Elasticsearch mới cần kết nối đến nó
Thứ hai, với yêu cầu về khả năng xây dựng ứng dụng mobile trong tương lai, việc áp dụng kiến trúc Client Server là hợp lý Kiến trúc này cho phép phát triển ứng dụng theo hai tầng - độc lập gồm có Client và server và lập trình viên có thể lựa chọn ngôn ngữ lập trình và nền tảng phát triển phù hợp Trong tương lai, việc xây dựng ứng dụng mobile cũng sẽ rất thuận tiện vì ta có thể tận dụng được phần Server đã có
5.1 Các mẫu kiến trúc đang sử dụng
5.1.1 Mẫu kiến trúc Client-server
Kiến trúc Client server là một mô hình trong đó hệ thống được chia thành hai vai trò: Client - (máy khách) và Server (Máy chủ) Trong kiến trúc này, Client sẽ gửi các yêu cầu đến Server, Server sẽ xử lý và trả lại cho Client phản hồi tương ứng Ưu điểm của kiến trúc Client-server:
- Phân tách hệ thống rõ ràng: Cho phép phân tách rõ ràng vai trò và trách nhiệm giữa client và server Server chịu trách nhiệm cung cấp dịch vụ, quản lý dữ liệu và xử lý yêu cầu, trong khi client chỉ tập trung vào việc sử dụng dịch vụ và tương tác với người dùng
- Tính mở rộng và linh hoạt: Dễ dàng mở rộng bằng cách thêm mới client hoặc server vào hệ thống Các server có thể được tăng cường hoặc tách ra thành các thành phần riêng biệt để xử lý tải cao hoặc mở rộng khả năng Với nhu cầu của hệ thống hiện tại là phát triển ứng dụng Mobile trong tương lai, đây là một điểm mạnh của kiến trúc
- Tính mạnh mẽ và hiệu suất: Với kiến trúc Client server, server có thể được tối ưu - hóa để xử lý tải lớn và đáp ứng nhanh chóng với yêu cầu từ nhiều client Điều này giúp tăng hiệu suất và cung cấp trải nghiệm tốt hơn cho người dùng
Nhược điểm của kiến trúc Client-server:
- Sự phụ thuộc vào server: Client phụ thuộc vào sự hoạt động của server Nếu server gặp sự cố hoặc không khả dụng, client không thể thực hiện được các yêu cầu và truy cập dịch vụ
- Single point of failure (Điểm lỗi duy nhất): Nếu server gặp sự cố, toàn bộ hệ thống có thể bị ảnh hưởng
- Độ trễ mạng: Sử dụng kiến trúc Client server yêu cầu gửi yêu cầu từ client đến - server thông qua mạng Việc truyền thông qua mạng có thể tạo ra độ trễ và làm giảm hiệu suất trong một số trường hợp
Kiến trúc Microservice là một kiểu kiến trúc phần mềm phân tán, trong đó ứng dụng được xây dựng thành một tập hợp các dịch vụ nhỏ độc lập hoạt động cùng nhau Mỗi dịch vụ (microservice) trong kiến trúc này thực hiện một chức năng cụ thể và có thể được triển khai, cập nhật và mở rộng độc lập với các dịch vụ khác
Trong kiến trúc Microservice, ứng dụng ban đầu được chia thành các thành phần nhỏ hơn gọi là microservices, mỗi microservice chạy trong quá trình riêng biệt và có thể sử dụng ngôn ngữ lập trình và công nghệ khác nhau Các microservices tương tác với nhau thông qua giao tiếp qua mạng, sử dụng giao thức như HTTP hoặc message queue
Hình 14 Kiến trúc tổng quan của hệ thống Akajob hiện tại
Trên đây là kiến trúc tổng quan của hệ thống Akajob sử dụng kiến trúc Microservice Trong đó các các thành phần:
- Client service: Là service có nhiệm vụ xây dựng giao diện, đóng vai trò tương tác với người dùng
- Microsoft identity platform: Là một kênh trung gian giúp người dùng đăng nhập vào hệ thống một cách nhanh chóng
- Identity server: Chịu trách nhiệm xác thực và xác định quyền truy cập của người dùng
- Aka service: Là một tập hợp các service liên quan đến các tác vụ của hệ thống
- Metada Service: Là một tập hợp gồm 2 service bao gồm Search service có nhiệm vụ truy vấn dữ liệu từ Elasticsearch và Data service có nhiệm vụ truy vấn dữ liệu từ CSDL ArangoDB
- SQL: Là một cơ sở dữ liệu quan hệ dùng chung cho tất cả các service của hệ thống
- Elasticsearch: là một công cụ được sử dụng để lưu trữ và truy xuất dữ liệu Nó cung cấp khả năng tìm kiếm nhanh chóng và phân tích dữ liệu thời gian thực
- ArangoDB: là một hệ quản trị cơ sở dữ liệu, được thiết kế để hỗ trợ lưu trữ và truy xuất dữ liệu dưới dạng đồ thị
Hình 15 Kiến trúc chi tiết hệ thống Akajob hiện tại a Tương tác giữa các service
Kịch bản use case
Đặc tả use case
3.2.2.1 Use case UC-01 “Đăng tuyển công việc” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA đăng đăng ký công việc b Tác nhân
Quản lý dự án c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền đăng ký công việc d Luồng sự kiện chính (đăng ký thành công)
- Bước 1: QLDA chọn chức năng “Tạo công việc”
- Bước 2: Hệ thống hiển thị giao diện Tạo công việc
- Bước 3: QLDA điền thông tin
- Bước 4: QLDA click vào nút Submit
- Bước 5: Hệ thống kiểm tra xem các trường bắt buộc đã được nhập hay chưa
- Bước 6: Hệ thống kiểm tra xem các trường đã nhập có hợp lệ hay không
- Bước 7: Hệ thống hiển thị Popup hỏi QLDA có muốn gửi mail cho các ứng viên tiềm năng hay không
- Bước 9: Hệ thống lưu thông tin công việc vào hệ thống và gửi mail cho các ứng viên tiềm năng
- Bước 10: Hệ thống redirect về trang chi tiết của công việc vừa tạo e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 5 Nếu QLDA nhập thiếu trường
Hệ thống báo lỗi cần nhập các trường yêu cầu
2 Bước 6 Nếu QLDA nhập thông tin không hợp lệ
Hệ thống báo lỗi thông tin không hợp lệ
Hệ thống lưu thông tin
CV nhưng không gửi mail cho các ứng viên
Bước 10 tiềm năng f Biểu đồ hoạt động
Hình 7 Biểu đồ hoạt động chức năng “Đăng tuyển công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Summary Tên công việc Có
2 Budgeted MM Quỹ MM Có
3 Project Code Mã dự án của công việc
4 Headcount Số người muốn thuê
5 Benefit Min Số tiền chi tối thiểu cho mỗi ứng viên
6 Benefit Max Số tiền chi tối đa cho mỗi ứng viên
7 Job title Tên vị trí cần tuyển
8 StartDate Ngày bắt đầu công việc
9 End Date Ngày kết thúc công việc
10 Contract Point Người liên hệ Có
13 Xjob purpose Mục đích thuê Có
15 Job description Mô tả công việc Có
16 Skills Kỹ năng yêu cầu Có
17 Level Level của kỹ năng
Có h Dữ liệu đầu ra
3.2.2.2 Đặc tả usecase UC 02 “Phê duyệt công việc”- a Giới thiệu
Usecase mô tả tương tác giữa Trưởng đơn vị và hệ thống khi Trưởng đơn vị phê duyệt công việc b Tác nhân
Trưởng đơn vị c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền Trưởng đơn vị
- QLDA đăng ký công việc trực thuộc phòng ban của Trưởng đơn vị d Luồng sự kiện chính (phê duyệt thành công)
- Bước 1: Trưởng đơn vị truy cập chi tiết công việc cần phê duyệt
- Bước 2: Hệ thống hiển thị màn hình chi tiết công việc
- Bước 3: Trưởng đơn vị click nút “Approve”
- Bước 4: Hệ thống hiển thị popup bao gồm các trường BudgetedMM (đang được hiển thị thông tin Budgeted MM mà QLDA đã nhập)
- Bước 5: Trưởng đơn vị chọn “Yes”
- Bước 6: Hệ thống kiểm tra xem trường bắt buộc đã được nhập chưa
- Bước 7: Hệ thống kiểm tra xem thông tin đầu vào có hợp lệ không
- Bước 8: Hệ thống cập nhật trạng thái cho công việc và gửi mail cho QLDA
- Bước 9: Hệ thống cập nhật lại màn chi tiết công việc e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu trưởng đơn vị click nút Reject và chọn Yes
Hệ thống hiện thị popup để nhập lý do từ chối và hai nút “Yes”, “Cancel”
Nếu chọn Yes, cập nhật trạng thái cho CV, gửi mail cho QLDA Cập nhật lại trang chi tiết
2 Bước 3 Nếu trưởng đơn vị click nút Reject và chọn
Nếu chọn Cancel, trở lại màn hình chi tiết CV
3 Bước 6 Nếu trưởng đơn vị xóa thông tin ở trường
Hệ thống báo lỗi cần nhập các trường yêu cầu
4 Bước 6 Nếu trưởng đơn vị chỉnh sửa thông tin
Bugeted MM và ấn yes
Hệ thống lưu cập nhật
CV với Budgeted MM mà Trưởng đơn vị vừa chỉnh sửa, gửi mail cho QLDA
Bước 9 f Biểu đồ hoạt động
Hình 8 Biểu đồ hoạt động chức năng “Phê duyệt công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Budgeted MM Quỹ MM h Dữ liệu đầu ra
3.2.2.3 Đặc tả usecase UC-03 “Ứng tuyển công việc” a Giới thiệu
Usecase mô tả tương tác giữa Ứng viên và hệ thống khi Ứng viên ứng tuyển vào công việc b Tác nhân Ứng viên c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt d Luồng sự kiện chính (ứng tuyển thành công)
- Bước 1: Ứng viên truy cập công việc
- Bước 2: Hệ thống hiển thị chi tiết công việc
- Bước 3: Ứng viên click “Apply”
- Bước 4: Hệ thống hiện thị popup xác nhận, bao gồm trường “Lý do ứng tuyển” và 2 button
- Bước 5: Ứng viên điền thông tin và ấn “Submit”
- Bước 6: Hệ thống kiểm tra trường bắt buộc
- Bước 7: Hệ thống lưu thông tin ứng viên vào hệ thống, gửi mail cho QLDA e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 4 Nếu ứng viên chọn
Quay lại màn chi tiết công việc
2 Bước 5 Nếu ứng viên không điền lý do ứng tuyển
Hệ thống báo lỗi yêu cầu nhập trường bắt buộc
Bước 4 f Biểu đồ hoạt động
Hình 9 Biểu đồ hoạt động chức năng “Ứng tuyển công việc” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Reason Lý do ứng tuyển
Có h Dữ liệu đầu ra
3.2.2.4 Đặc tả usecase UC-04 “Thuê ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA thuê ứng viên b Tác nhân
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt
- Ứng viên đã ứng tuyển vào công việc d Luồng sự kiện chính (thuê thành công)
- Bước 1: QLDA truy cập danh sách ứng viên
- Bước 2: Hệ thống hiển thị danh sách ứng viên
- Bước 3: QLDA click nút “Hire” với ứng viên tương ứng
- Bước 4: Hệ thống hiển thị popup điền thông tin thuê
- Bước 5: QLDA nhập thông tin và ấn “Hire”
- Bước 6: Hệ thống kiểm tra các trường bắt buộc
- Bước 7: Hệ thống kiểm tra dữ liệu đầu vào có hợp lệ không
- Bước 8: Hệ thống lưu thông tin ứng viên và gửi mail cho trưởng đơn vị
- Bước 9: Cập nhật lại màn danh sách ứng viên e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu QLDA click “Add candidate”
Hiển thị form giống ở bước 4 nhưng tại trường Account, QLDA sẽ nhập account của ứng viên muốn tuyển
2 Bước 6 Nếu QLDA không điền các trường bắt buộc
Hệ thống báo lỗi yêu cầu nhập trường bắt buộc
3 Bước 7 Nếu QLDA điền thông tin không hợp lệ bao gồm:
Hệ thống hiển thị lỗi thông tin không hợp lệ
Bước 4 viên không phù hợp của Công việc
- Ứng viên chưa hoàn thành ít nhất 90% công việc ở dự án chính của mình
- Tổng tiền thuê (bao gồm MM * giá mỗi MM) > số tiền tối đa ở mục chi tiết CV f Biểu đồ hoạt động
Hình 10 Biểu đồ hoạt động chức năng “Thuê ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 Account Account ứng viên Có
2 Job Vị trí của ứng viên
3 From Ngày bắt đầu thuê Có
4 To Ngày kết thúc thuê Có
6 MM Số MM muốn thuê Có
7 Cost per MM Giá mỗi MM muốn thuê
Phạm vi công việc Có h Dữ liệu đầu ra
3.2.2.5 Đặc tả usecase UC-05 “Phê duyệt ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa Trưởng đơn vị và hệ thống khi Trưởng đơn vị thuê ứng viên b Tác nhân
Trưởng đơn vị c Tiền điều kiện
- Đã đăng nhập vào hệ thống
- Có quyền Trưởng đơn vị
- Công việc đã được trưởng đơn vị phê duyệt
- QLDA của công việc trực thuộc phòng ban của trưởng đơn vị
- Ứng viên đã được QLDA thuê d Luồng sự kiện chính (phê duyệt thành công)
- Bước 1: Trưởng đơn vị truy cập danh sách ứng viên chờ phê duyệt
- Bước 2: Hệ thống hiển thị danh sách ứng viên chờ phê duyệt
- Bước 3: Trưởng đơn vị click nút “Approve”
- Bước 4: Hệ thống hiển thị popup gồm các trường như số MM, giá mỗi MM và tổng số tiền Trường MM và giá mỗi MM có giá trị khởi tạo là giá trị là QLDA đã nhập, các trường này có thể sửa được
- Bước 5: Trưởng đơn vị click nút “Agree”
- Bước 6: Hệ thống kiểm tra các trường bắt buộc
- Bước 7: Hệ thống kiểm tra tính hợp lệ của dữ liệu đầu vào
- Bước 8: Hệ thống cập nhật trạng thái và các thông tin sửa đổi nếu có cho ứng viên, gửi mail cho QLDA và ứng viên e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 3 Nếu Trưởng đơn vị click “Reject”, sau đó chọn Yes
Hiển thị form yêu cầu nhập lý do từ chối Nếu chọn Yes, hệ thống validate trường bắt buộc
Hệ thống cập nhật thông tin của ứng viên
2 Bước 3 Nếu Trưởng đơn vị click “Reject”, sau đó chọn No Đóng popup, trở lại màn hình trước đó
3 Bước 6 Nếu các trường bắt buộc không được nhập
Hệ thống báo lỗi yêu cầu nhập các trưởng bắt buốc
4 Bước 7 Nếu Trưởng đơn vị sửa đổi số MM và giá mỗi
Hệ thống kiểm tra xem thông tin nhập có hợp lệ không, báo lỗi trong các trường hợp sau:
- Nếu số MM lớn hơn số Budgeted
- Tổng giá lớn hơn tổng số tiền chi tối đa ở trong phần thông tin công việc
Bước 4 f Biểu đồ hoạt động
Hình 11 Biểu đồ hoạt động chức năng “Phê duyệt ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 MM Số MM đồng ý duyệt
2 Cost per MM Giá mỗi MM đồng ý duyệt h Dữ liệu đầu ra
3.2.2.6 Đặc tả usecase UC 06 “- Chi trả ứng viên” a Giới thiệu
Usecase mô tả tương tác giữa QLDA và hệ thống khi QLDA chi trả cho ứng viên b Tác nhân
- Đã đăng nhập vào hệ thống
- Công việc đã được trưởng đơn vị phê duyệt
- Ứng viên đã được đồng ý phê duyệt bởi Trưởng đơn vị d Luồng sự kiện chính (chi trả thành công)
- Bước 1: QLDA truy cập chi tiết công việc
- Bước 2: Hệ thống hiển thị chi tiết công việc
- Bước 3: QLDA chọn tab “Manage your candidates”
- Bước 4: Hệ thống hiển thị danh sách ứng viên
- Bước 5: QLDA click nút “Payment”
- Bước 6: Hệ thống hiển thị popup hiển thị thông tin các payment đã được tạo cho ứng viên đó
- Bước 7: QLDA click “New Payment”
- Bước 8: Hệ thống hiển thị popup để QLDA nhập số MM muốn chi trả
- Bước 7: QLDA điền số MM muốn chi trả, click “Submit”
- Bước 9: Hệ thống kiểm tra các trường bắt buộc
- Bước 10: Hệ thống kiểm tra thông tin nhập vào có hợp lệ không
- Bước 11: Hệ thống tạo yêu cầu chi trả thành công, gửi mail cho trưởng đơn vị e Luồng sự kiện thay thế
Các luồng sự kiện phụ, có thể khiến chức năng hoạt động khác luồng chính:
STT Vị trí Điều kiện Hành động Vị trí tiếp tục
1 Bước 9 Nếu QLDA không nhập số MM
Hệ thống báo lỗi, yêu cầu nhập các trường bắt buộc
2 Bước 10 Nếu QLDA nhập số
Hệ thống kiểm tra nếu QLDA nhập số MM chi trả lớn hơn số MM còn lại của ứng viên, báo lỗi thông tin không hợp lệ
Bước 8 f Biểu đồ hoạt động
Hình 12 Biểu đồ hoạt động chức năng “Chi trả ứng viên” g Dữ liệu đầu vào
TT Trường Mô tả Bắt buộc Điều kiện hợp lệ
1 MM Số MM muốn chi trả h Dữ liệu đầu ra
Dựa trên các yêu cầu nghiệp vụ ban đầu, hệ thống cần phải thỏa mãn các tiêu chí sau:
- Là một hệ thống website đa tác vụ, trong đó mỗi tác vụ có một nhiệm vụ riêng nhưng vẫn sẽ có những sự liên kết ở mức thấp
- Hệ thống có thể tích hợp được với nhiều bên khác bao gồm các hệ thống nội bộ của công ty, các hệ thống đào tạo trực tuyến như Udemy, Udacity,…
- Có thể dễ dàng mở rộng các tính năng mới trong tương lai
- Có thể xây dựng ứng dụng mobile trong tương lai
- Có sử dụng hệ thống Elasticsearch và phải đảm bảo tốc độ phản hồi nhanh (cụ thể là dưới 1s)
Dựa trên yêu cầu trên, hai mô hình kiến trúc đã được sử dụng kết hợp đó là Client-Server và Microservice
Hình 13 Ý tưởng kiến trúc sử dụng
Thứ nhất, có thể thấy các tác vụ nêu trên là các tác vụ riêng biệt, việc sử dụng Microservice sẽ đảm bảo các tác vụ trên có thể hoạt động một cách độc lập, không bị phụ thuộc lẫn nhau Ngoài ra, hệ thống Akajob cũng là một kênh trung gian để giao tiếp giữa các hệ thống khác trong nội bộ công ty và ngoài công ty, hay nói cách khác là hệ thống sẽ cần tích hợp, tương tác thường xuyên với các hệ thống khác Việc dễ dàng mở rộng các tính năng độc lập mới trong tương lai cũng sẽ rất thuận lợi khi quá trình phát triển, triển khai tính năng mới sẽ không làm ảnh hưởng đến các chức năng đang hoạt động Thêm vào đó, với việc yêu cầu sử dụng Elasticsearch, mô hình Microservice tỏ ra vượt trội khi mỗi service có thể sử dụng một công nghệ riêng, một cơ sở dữ liệu riêng, chỉ các service cần sử dụng Elasticsearch mới cần kết nối đến nó
Thứ hai, với yêu cầu về khả năng xây dựng ứng dụng mobile trong tương lai, việc áp dụng kiến trúc Client Server là hợp lý Kiến trúc này cho phép phát triển ứng dụng theo hai tầng - độc lập gồm có Client và server và lập trình viên có thể lựa chọn ngôn ngữ lập trình và nền tảng phát triển phù hợp Trong tương lai, việc xây dựng ứng dụng mobile cũng sẽ rất thuận tiện vì ta có thể tận dụng được phần Server đã có
Các mẫu kiến trúc đang sử dụng
Công nghệ sử dụng
Hình 16 Công nghệ sử dụng trong hệ thống Akajob
Thiết kế tổng quan
Hình 17 Kiến trúc tổng quan theo mô hình Client-Server Đối với kiến trúc Client – Server, hệ thống sẽ được chia thành hai phần Frontend và Backend để có thể lựa chọn công nghệ một cách linh hoạt sao cho phù hợp nhất với mỗi phần Thêm vào đó, việc tách hệ thống có thể giúp chia nhân lực phát triển thành 2 đội, từ đó giúp chia nhỏ khối lượng công việc, cũng như tăng khả năng mở rộng
Hình 18 Cấu trúc liên kết giữa Client và Server
Thiết kế Front-end
Frontend sử dụng Framwork Angular Angular là một framework JavaScript mã nguồn mở được phát triển bởi Google Nó được sử dụng để xây dựng ứng dụng web đơn trang (single- page applications - SPAs) và ứng dụng web đa trang (multi-page applications) phức tạp Angular giúp tạo ra các ứng dụng web mạnh mẽ, linh hoạt và dễ bảo trì
Angular sử dụng mô hình MVVM, cho phép tách biệt rõ ràng giữa logic ứng dụng và giao diện người dùng Điều này giúp phát triển ứng dụng dễ dàng hơn và cải thiện khả năng kiểm tra và bảo trì
Angular cung cấp tính năng binding dữ liệu hai chiều, cho phép dữ liệu được đồng bộ hóa tự động giữa các thành phần giao diện người dùng và dữ liệu ứng dụng Điều này giúp giảm thiểu lượng mã lập trình và tăng khả năng tương tác của người dùng
Angular hỗ trợ Dependency Injection (DI), cho phép các thành phần ứng dụng có thể tương tác và tái sử dụng dễ dàng DI giúp giảm sự phụ thuộc và tạo ra các thành phần dễ kiểm tra và bảo trì a Component
Hình 19.Thiết kế một component trong Angular
Component là một khối cơ bản bao gồm một lớp Javascript/Typescript chịu trách nhiệm xử lý dữ liệu và logic trước khi binding ra tempate, một lớp template HTML để hiển thị dữ liệu đã được xử lý và một lớp CSS Một component có thể được hiểu là một phần giao diện độc lập, có thể được tái sử dụng và tương tác với các component khác Nó định nghĩa các logic xử lý và trạng thái của một chức năng cụ thể của ứng dụng b Module
Hình 20.Thiết kế một module trong Angular
Module có thể coi là cấp cao hơn của component Một module có thể bao gồm nhiều component và service Module là một tập hợp các tính năng liên quan đến nhau Ví dụ trong hệ thống Akajob, các tính năng liên quan đến Job như đăng tuyển Job, tuyển dụng ứng viên,… được nhóm vào một module
Một ứng dụng Angular sẽ bao gồm nhiều Module, tuy nhiên sẽ có một module gốc, nó sẽ khởi tạo ứng dụng và gọi các module khác Các component từ bất kỳ module nào cũng có thể truy cập vào component và service của module khác
Module trong Angular giúp tách biệt các tính năng của ứng dụng thành các phần nhỏ, giúp quản lý mã nguồn dễ hơn Ngoài ra nó cũng cung cấp một cách tổ chức và sắp xếp các thành phần và cho phép chia sẻ tính năng giữa các module khác nhau c Luồng hoạt động
Hình 21 Luồng hoạt động của ứng dụng Angular
Main.ts sẽ là điểm khởi tạo của ứng dụng Sau đó, main.ts sẽ khởi tạo AppModule (hay chính là Module gốc của ứng dụng) AppModule sẽ load các module khác và các service thông qua DI Sau đó AppModule sẽ khởi tạo AppComponent AppComponent có thể sử dụng bất kỳ component nào khác đã đăng ký thông qua Directive.
Thiết kế Backend
Thiết kế tổng quan
Backend sẽ được xây dựng dựa trên kiến trúc Microservice như đã đề cập ở phần 5 Dựa trên các nhược điểm đã phân tích ở trên, em xin đề xuất kiến trúc mới như sau
Thứ nhất, hiện tại số lượng service đang tương đối nhiều, nhóm xin đề xuất nên chia lại các service theo 4 nghiệp vụ lớn của hệ thống bao gồm Profile, Job, Learning, ResourceAllocation Ngoài ra, nhóm đề xuất thay thế RabbitMQ bằng Azure event grid Azure event grid là một dịch vụ giao tiếp sự kiện phân tán dựa trên event grid, bất cứ service nào cũng có thể đăng ký và publish sự kiện, điều này giúp tăng tính linh hoạt hơn, không giống như RabbitMQ là một message queue với cơ chế FIFO
Thứ hai, ở thời điểm bắt đầu xây dựng hệ thống, số lượng service còn ít, nên việc giao tiếp giữa Client và Server hay giữa các Server với nhau chưa gặp nhiều khó khăn Tuy nhiên, tính đến thời điểm hiện tại, số lượng service đã tăng lên đáng kể, khiến cho việc quản lý các kết nối giữa Client và Server gặp nhiều khó khăn Khi này, lập trình viên phải khai báo rất nhiều URL cho từng API, phải kiểm soát được request này được gửi đến service nào Do đó, việc áp dụng API Gateway trong hệ thống là rất cần thiết ở thời điểm hiện tại
API Gateway mang lại một số lợi ích sau:
- Giúp quản lý nhiều service một cách dễ dàng, nó cho phép định tuyến các request gửi đến, chuyển đổi các giao thức và xử lý lỗi một cách dễ dàng
- Giúp giảm tải cho các service ở phía Backend bằng cách tổng hợp cách tổng hợp các request hoặc response, sử dụng caching, điều này giúp tăng năng suất hệ thống
- Việc xác thực và ủy quyền từ client cũng trở nên dễ dàng hơn, kiểm soát truy cập đến các service ở Backend và mã hóa thông tin truyền qua mạng, giúp tăng tính bảo mật của hệ thống
Tuy nhiên, nó cũng có một vài nhược điểm:
- Do là điểm trung gian kết nối giữa Client và Server, nếu API Gateway gặp sự cố, toàn bộ hệ thống sẽ bị ảnh hưởng
- Việc thêm, sửa, xóa các service có thể yêu cầu thay đổi cấu hình trong API Gateway
- Hiệu năng của hệ thống phụ thuộc vào API Gateway, nếu nó không được tối ưu hoặc có khả năng chịu tải lớn
Hình 22 Kiến trúc đề xuất cải tiến
Thứ , hiện tại các service đang sử dụng chung một cơ sở dữ liệu quan hệ Tại thời điểm ba thiết kế ban đầu, khối lượng nghiệp vụ và số lượng các service còn chưa nhiều nên việc sử dụng chung một cơ sở dữ liệu chưa gặp nhiều khó khăn Tuy nhiên về sau, khi các tác vụ độc lập khác được thêm vào hệ thống, số lượng service tăng lên khiến cho số lượng bảng trong cơ sở dữ liệu cũng tăng lên đáng kể và các bảng này hoàn toàn không có ràng buộc và liên quan gì đến các bảng trước đó Điều này làm tăng tính phụ thuộc của hệ thống, nếu cơ sở dữ liệu gặp sự cố, toàn bộ các tính năng khác sẽ không thể hoạt động Do đó nhóm đề xuất chia lại cơ sở dữ liệu hiện tại thành nhiều cơ sở dữ liệu khác nhau, mỗi một service sẽ kết nối đến một cơ sở dữ liệu tương ứng với nghiệp của của nó Điều này cũng giúp giảm tải cho hệ thống, thay vì để các yêu cầu xử lý của các service tập trung vào một điểm
Thứ , hiện tại hệ thống đang chưa có một cơ chế, cách thức nào để giám sát, kiểm tra tình tư trạng các service, cũng như trực quan hóa dữ liệu Elasticsearch và nhật ký Do đó, nhóm xin đề xuất tạo thêm một service cho admin bao gồm các chức năng như HealthCheck các service, có thể xem được nhật ký hệ thống và theo dõi dữ liệu Elasticsearch một cách trực quan
Thiết kế service
Hình 23 Kiến trúc Service Job
Mỗi service sẽ bao gồm các tầng:
- Controller: Tầng tiếp nhận request được gửi tới từ client, có nhiệm vụ kiểm tra tính hợp lệ các tham số đầu vào, sau đó gọi đến các hàm ở tầng CommandHandler để xử lý logic
- CommandHandler: Tầng Controller giao tiếp với tầng CommandHandler thông qua các Command Sau đó, tầng CommandHandler sẽ thực hiện xử lý các logic nghiệp vụ của hệ thống, thao tác với cơ sở dữ liệu thông qua tầng Repository
- Tầng Repository: tầng này có nhiệm vụ trung gian giúp truy vấn, thao tác với cơ sở dữ liệu
- Tầng Model: chứa các model đại diện cho các bảng trong cơ sở dữ liệu Tầng Repository sẽ dựa trên các model để thực hiện thao tác với bảng tương ứng trong cơ sở dữ liệu
Thiết kế kiến trúc theo khía cạnh tĩnh
Hình 24 Biểu đồ gói của service Job
Trên đây là Biểu đồ gói của Service Job, bao gồm 3 gói con chính là JobService.API, JobService.Domain và JobService.Infrastructure
Gói JobService.API: chứa các thông tin khởi tạo của service như chuỗi kết nối cơ sở dữ liệu, các cấu hình dùng chung của toàn hệ thống, và quan trọng nhất là chứa các Controller Các Controller là đầu mối tiếp nhận các request được gửi đến, chuyển đổi thành các hành động cụ thể và gọi các phương thức tương ứng ở tầng Domain Ngoài ra, Controller cũng chịu trách nhiệm xử lý các tham số đầu vào, xác thực người dùng, xử lý lỗi và trả về kết quả cho phía Client
Gói JobService.Domain: Gói này phụ trách tiếp nhận thông tin từ Controller và xử lý logic nghiệp vụ, bao gồm các lớp đại diện cho các khái niệm và quy tắc nghiệp vụ của hệ thống Gói này cũng sẽ bao gồm các đối tượng, các lớp dịch vụ và phương thức để thực hiện các chứng năng chính của hệ thống Các gói con bao gồm:
- Command: Chứa các lớp command, có nhiệm vụ trung chuyển dữ liệu từ Controller tới CommandHandler tương ứng
- CommandHandler: Nhận các command từ Controller, xử lý dữ liệu nhận được và thực hiện các hành động thêm, sửa, xóa với các lớp ở tầng Infrastucture Gói này là gói xử lý các nghiệp vụ chính của hệ thống
- Queries: Gói này chứa các lớp có nhiệm vụ truy vấn dữ liệu, tương tác với các gói của tầng Infastruscture
- Event: Gói này chứa các lớp được sử dụng để làm một sự kiện của service
- EventHandler: Gói này chứa các lớp thực hiện các logic khi nhận được sự kiện từ hàng đợi của RabbitMQ
- Request: Gói này chứa các lớp đại diện cho thông tin đầu vào
- Response: Gói này chứa các lớp đại diện cho thông tin đầu ra
Gói JobService.Infrastructurer: Gói này bao gồm các lớp có nhiệm vụ giao tiếp trực tiếp với cơ sở dữ liệu và hỗ trợ các các lớp ở gói trên, bao gồm:
- Context: chứa lớp có nhiệm vụ thiết lập và duy trì kết nối với cơ sở dữ liệu, định nghĩa các đối tượng DbSet tương ứng với các bảng trong cơ sở dữ liệu Mỗi DbSet cung cấp các phương thức để truy vấn, thêm, sửa xóa từ các bảng tương ứng, liên kết các đối tượng DbSet với các lớp đại diện cho các bảng trong cơ sở dữ liệu, mô tả cấu trúc và quan hệ giữa các bảng
- Repository: gồm các lớp giúp truy cập và thao tác với cơ sở dữ liệu, mỗi một repository tương ứng với một model đại diện cho một bảng trong cơ sở dữ liệu
- Configurations: gồm các lớp giúp định nghĩa quy tắc cho các thuộc tính của đối tượng khi được lưu trong cơ sở dữ liệu b Biểu đồ lớp
Hình 25 Biểu đồ lớp một số chức năng của service Job
Trên đây là biểu đồ lớp liên quan đến luồng nghiệp vụ kết nối QLDA và ứng viên Bao gồm các lớp như:
- JobsController: tiếp nhận các HTTP request từ phía client, xử lý dữ liệu đầu vào thông qua các request model
- Jobsv2Query: xử lý các nghiệp vụ liên quan đến việc truy vấn dữ liệu từ CSDL
- Các lớp Command: đại diện cho các hành động mà Controller gửi tới CommandHandler
- Các lớp CommandHandler: xử lý logic nghiệp vụ của hệ thống dựa trên các command nhận được từ Controller
- Lớp context: định nghĩa các DbSet tương ứng với các bảng trong CSDL
- Lớp Repository: Có nhiệm vụ truy vấn, sửa đổi dữ liệu của CSDL
- Lớp Jobsv2, Jobsv2ApplyHistory là các lớp model, đại diện cho các bảng trong CSDL c Biểu đồ triển khai
Hình 26 Biểu đồ triển khai hiện tại của hệ thống akajob
Hệ thống Akajob được triển khai trên Cloud, cụ thể là Microsoft Azure Các service được triển khai trên hai máy ảo chạy hệ điều hành window Máy ảo 1 bao gồm các identity service và các service nghiệp vụ khác như Job, Profile,… và được cài đặt RabbitMQ Ngoài ra các cron job liên quan đến nghiệp vụ đồng bộ dữ liệu từ các hệ thống bên ngoài cũng được triển khai trên máy ảo này
Máy ảo thứ 2 bao gồm các service liên quan đến lưu trữ dữ liệu như Search service kết nối đến một server elastic search và data service, kết nối đến CSDL ArangoDB Ngoài ra một job đồng bộ data hàng ngày từ CSDL quan hệ về Elasticsearch và ArangoDB cũng được triển khai trên máy ảo này
CSDL quan hệ được triển khai trên nền tảng SQL Database của Microsoft Azure
Thiết kế kiến trúc theo khía cạnh động
Hình 27 Biểu đồ trình tự chức năng “Đăng tuyển công việc”
Hình 28 Biểu đồ trình tự chức năng “Ứng tuyển công việc”
Đánh giá mẫu kiến trúc hiện tại
- Với việc sử dụng kiến trúc Microservice, hệ thống đã được chia thành các service nhỏ độc lập với nhau
- Kiến trúc Client server cũng giúp phân chia logic giữa máy khách và máy chủ - Với các kiến trúc trên, hệ thống đảm bảo được nguyên lý “Chia để trị” b Increase cohesion
- Kiến trúc Microservice cho phép mỗi service tập trung vào một nhiệm vụ cụ thể, đảm bảo tính nhất quán và rõ ràng trong việc xử lý chức năng của nó
- Kiến trúc Client server cũng tách biệt rõ ràng giữa máy khách và máy chủ, trong đó - máy khách thực hiện các công việc tương tác trực tiếp với người dùng, còn máy chủ sẽ chịu trách nhiệm lưu trữ quản lý data, xử lý logic nghiệp vụ, tương tác với các thành phần khác trong hệ thống,… c Reduce coupling
- Ở hệ thống hiện tại, với kiến trúc microservice, hệ thống đang được chia thành các service hoạt động độc lập với nhau và các service giao tiếp với nhau thông qua các message Do đó, các service sẽ không bị phụ thuộc lẫn nhau trúc Microservice cho phép mỗi service tập trung vào một nhiệm vụ cụ thể, đảm bảo tính nhất quán và rõ ràng trong việc xử lý chức năng của nó
- Hiện tại, các service đang kết nối chung đến một cơ sở dữ liệu, thông thường điều này sẽ làm tăng mức độ phụ thuộc giữa các service và tăng rủi ro khi thay đổi cơ sở dữ liệu dùng chung Tuy nhiên hiện tại, việc truy cập cơ sở dữ liệu đang được thực hiện qua các lớp trung gian (ví dụ như Repository), điều này giúp làm giảm mức độ Common Coupling
- Bằng việc sử dụng các Interface, các thành phần sẽ không bị phụ thuộc vào luồng thực thi của các thành phần khác, từ đó làm giảm mức độ Control Coupling giữa hai thành phần d Increase abstraction
- Kiến trúc Microservice và Client server đều cho phép bạn tạo ra các mô hình trừu - tượng riêng cho mỗi dịch vụ hoặc phía máy chủ, che dấu chi tiết triển khai cụ thể
- Kiến trúc Event-driven với việc sử dụng mô hình Pub/sub cho phép các thành phần gửi sự kiện không biết về các thành phần đang đăng ký Các thành phần chỉ cần quan tâm đến các sự kiện mà chùng quan tâm, không cần biết chi tiết về các thành phần khác
Cả ba kiến trúc trên đều có thể được thiết kế dựa trên các Interface, giúp đảm bảo tính trừu tượng của hệ thống e Increase reuse
- Kiến trúc Microservice và Client server giúp tăng khả năng tái sử dụng Cụ thể trong - Microservice ta có thể tái sử dụng các service còn trong mô hình Client-server, ta có thể tái sử dụng phần server để phát triển trên một Client mới f Increase flexibility
- Với việc sử dụng Microservice và Event driven, ta có thể dễ dàng thay đổi, mở rộng - và nâng cấp dễ dàng cho từng service
- Kiến trúc Client server cũng cho phép thay đổi logic ở phía máy khách và máy chủ - một cách độc lập g Anticipate obsolescence
- Việc chia nhỏ hệ thống thành các service giúp dễ dàng thay thế hoặc nâng cấp các service đã bị lỗi thời
- Kiến trúc Client server cũng giúp tách biệt giữa phần xử lý logic và tương tác người - dùng, giúp việc thay đổi và nâng cấp công nghệ dễ dàng hơn h Design for portability
- Ba kiến trúc trên đều có khả năng chạy trên nhiều môi trường khác nhau Từ đó đảm bảo tính di động và khả năng tương thức Ngoài ra, với sự phát triển của công nghệ ảo hóa giúp việc triển khai trên các môi trường khác nhau trở nên dễ dàng hơn i Design for testability
- Việc tách nhỏ các nghiệp vụ có thể giúp kiểm thử trên từng nghiệp vụ dễ dàng hơn
- Tuy nhiên, việc kiểm thử tích hợp lại trở nên khó khăn hơn do phải nắm rõ tương tác giữa các service g Design for Defensively
- Việc tách nhỏ các server sẽ giúp giảm thiểu các trường hợp không mong muốn, nếu một service có vấn đề, các service khác không bị ảnh hưởng, giúp giảm phạm vi ảnh hưởng
- Tuy nhiên, với việc chia hệ thống thành các service nhỏ cũng như chia hệ thống theo mô hình Client-Server, việc kiểm soát để hệ thống không gặp phải các ngoại lệ, các tình huồng không mong muốn yêu cầu lập trình viên phải xử lý nhiều hơn
Đánh giá mã nguồn
- Content coupling: Ảnh dưới mô tả một lớp User bao gồm các thuộc tính khác nhau, trong đó có một thuộc tính chứa thông tin nhạy cảm đó là Rank Rank có thể tượng trưng cho khoảng lương của người dùng Trong nghiệp vụ hiện tại, thuộc tính này là một điều kiện để kiểm tra điều kiện ứng tuyển của ứng viên Trong mã nguồn dưới đây, thuộc tính Rank đang sử dụng các phương thức public getter và setter, điều này vi phạm content coupling do các đối tượng khác hoàn toàn có thể get thông tin này Giải pháp đưa ra là tạo một phương thức để kiểm tra điều kiện ứng tuyển ở trong lớp User
Hình 29 Mã nguồn ví dụ về vi phạm Content coupling
- Common coupling: mã nguồn trong dự án không thay đổi dữ liệu chung như biến toàn cục,…
- Control coupling: phương thức trên đã vi phạm tiêu chí Control coupling do sử dụng tham số đầu vào “type” để quyết định luồng hoạt động
Hình 30.Mã nguồn ví dụ về vi phạm Control coupling
- Stamp Coupling: mã nguồn trong dự án vi phạm khác nhiều tiêu chí này, ví dụ trong ảnh dưới đây có tham số đầu vào là một đối tượng Jobsv2 có rất nhiều thuộc tính, tuy nhiên phương thức chỉ sử dụng một vài thuộc tính của đối tượng Do đó các thuộc tính khác có thể tăng độ phức tạp cho mã nguồn hoặc có thể gây lộ dữ liệu
Hình 31 Mã nguồn ví dụ về vi phạm Stamp coupling b Cohesion
- Coincidental cohesion: trong mã nguồn bên dưới, nhiều tác vụ không liên quan đến nhau nhưng đang được đặt trong cùng một phương thức Điều này vi phạm coincidental cohesion
- Logical cohesion: Tương tự như mã nguồn vi phạm Control coupling ở trên, hai tác vụ tính điểm đang đặt chung trong một phương thức nhưng logic tính toán lại hoàn toàn khác nhau
- Temporal cohesion: trong mã nguồn bên dưới, các tác vụ không liên quan đến nhau về mặt chức năng như đọc config, khởi tạo logger,… được thực thi khi khởi chạy mã nguồn Điều này vi phạm temporal cohesion Từ đó mã nguồn sẽ bị dàn trải, khó tái sử dụng
Hình 32 Mã nguồn ví dụ về vi phạm Temporal cohesion
- Procedural cohesion: Mã nguồn bên dưới đa vi phạm tiêu chí này, các phương thức syncFsu(), syncBu(), syncBranch() được thực hiện tuần tự tuy nhiên logic tính toán bên trong mỗi phương thức lại khác nhau.
Hình 33 Mã nguồn ví dụ về vi phạm Procedural coupling
- Functional cohesion: đa số các lớp xử lý logic đều tuân thủ tiêu chí này, do hệ thống đang sử dụng mẫu thiết kế CQRS, mỗi command handler chỉ chịu trách nhiệm xử lý liên quan đến một logic duy nhất c Các nguyên tắc SOLID
- Single Responsibility Principle: Hiện tại, theo mô hình CQRS, mỗi một lớp xử lý logic đều chỉ thực hiện một tác vụ duy nhất Tuy nhiên, vẫn có một vài module chưa tuân thủ theo nguyên tắc này.
