Tìm hiểu Blockchain

Chiến lược Blockchain của FPT Software

Với năng lực về công nghệ cũng như các kiến thức về tên miền trong lĩnh vực Blockchain, FPT Software đã đề xuất các giải pháp để tăng lợi nhuận cũng như tăng năng suất cho các doanh nghiệp khách hàng. Trước khi thực hiện điều này, FPT Software dành nhiều năm để thực hiện các chương trình Blockchain cho cả nội bộ lẫn bên ngoài. Hiện tại, các dịch vụ Blockchain của FPT Software bao gồm:

Về Phát triển Blockchain, FPT Software cung cấp dịch vụ phát triển trọn vòng đời dự án, phân tích yêu cầu, phát triển ứng dụng, kiểm thử, và bảo trì.

Dịch vụ của FPT Software cũng không chỉ hạn chế ở phần mềm, mà còn bao gồm việc xây dựng sản phẩm để thúc đẩy năng lực của Blockchain. Đây là dịch vụ về hệ thống phi tập trung, quản lý độ trung thành của khách hàng, cùng nền tảng cho khách hàng thân thiết. Hệ thống quản lý nói trên của FPT Software có tên gọi là Akaminds.

Thành tựu của FPT trong lĩnh vực Blockchain

Hiểu được về tiềm năng của công nghệ Blockchain, FPT Software hiện đang xây dựng tài nguyên cho công nghệ này, cũng như tổ chức seminar để chia sẻ về các kinh nghiệm phát triển Blockchain. FPT Software đã giành được 2 dự án, với 7 tài nguyên cho mỗi dự án, phục vụ cho một hãng hàng không lớn và một công ty kiểm toán tài chính tại Singapore. Đồng thời, FPT đã hợp tác với SBI Ripple Asia và Factom, nhằm cải thiện năng lực hơn nữa, cũng như hỗ trợ trong công tác presale.

Dịch vụ Tài chính Ngân hàng

• Hơn 35 khách hàng cho dịch vụ Tài chính Ngân hàng và Bảo hiểm;
• Hơn 1000 đầu người tại BFSI, với các mô hình chuyển phát toàn cầu tại Hoa Kỳ, Nhật Bản, Châu Âu, và APAC;
• Hơn 20 kinh nghiệm trong cung cấp dịch vụ về Tài chính và Ngân hàng.

Tài nguyên Blockchain

• 20 chuyên gia trong nghiên cứu và phát triển Blockchain;
• Hơn 60 kỹ sư giàu kinh nghiệm đang làm việc cho các dự án Blockchain;
• Hơn 10 chứng chỉ về phát triển Blockchain và 2 chứng chỉ Chuyên gia Blockchain.

Đối tác

• SBI Ripple Asia;
• Factom.

Case Study: KYC (Know Your Customer) – Hiểu khách hàng của bạn

Khách hàng là một mạng lưới quốc tế với các công ty thành viên cung cấp các dịch vụ kiểm toán, thuế, và tư vấn. Họ làm việc rất gần với khách hàng, nhằm giảm thiểu rủi ro và nắm bắt cơ hội.

Nhu cầu doanh nghiệp

Trong nỗ lực trở thành một trung tâm tài chính thông minh hàng đầu, cần phát triển một hạ tầng kỹ thuật chung cho ID số và KYC, giúp hỗ trợ các cơ sở tài chính và những bên liên quan chia sẻ và xác minh các thông tin cá nhân của khách hàng, thông qua nền tảng DLT (Distributed Ledger Technology – Công nghệ sổ cái phân tán).

ID số và KYC sẽ hỗ trợ 4 trải nghiệm người dùng chính:

• Tạo hồ sơ đầu tiên cho khách hàng mới;
• Lấy lại các thông tin từ hồ sơ có sẵn;
• Cập nhật một hồ sơ có sẵn;
• Kiểm toán các sự kiện có liên quan tới một khách hàng cụ thể.

Để đạt được tầm nhìn, nền tảng yêu cầu phải có một hệ sinh thái mạnh mẽ, có khả năng mở rộng quy mô trên nhiều khu vực và địa lý khác nhau, thông qua cung cấp dịch vụ và tính năng chuyên môn nhằm chia sẻ dữ liệu, qua đó cải thiện và đẩy nhanh KYC cũng như quy trình onboarding người dùng.

Giải pháp

FPT chịu trách nhiệm triển khai nền tảng Blockchain và phát triển UI.

• Thiết kế một hệ thống cho phép các đơn vị tài chính lưu trữ một sổ consortium, sau đó thu lại các thông tin KYC khi có sự cho phép của khách hàng.
• Đảm bảo bảo mật tất cả các tài liệu hỗ trợ của khách hàng, đồng thời lưu giá trị băm của chúng vào sổ consortium để phòng tránh các cập nhật có ủy quyền.
• Tạo dấu vết kiểm toán không cho phép can thiệp với mọi hoạt động đọc/viết/truy cập.

FPT đề xuất hệ thống kiến trúc eKYC để thúc đẩy công nghệ Blockchain mới nhất.

Frontend

• UI được tủy chỉnh và nền tảng số cho phép khách hàng hoặc người dùng được truy cập vào hệ thống eKYC.

Backend

• Các hệ thống nội bộ cần thiết để thực hiện eKYC.

Mã hóa tài liệu

• Mã hóa các tài liệu của khách hàng (như hộ chiếu, ID…) và lưu trữ chúng trên Azure Blob Storage.

Tích hợp bên thứ 3

• Kết nối với các bên thứ 3 khác và sử dụng một hệ thống ngoại vi để lấy dữ liệu;
• Cung cấp API cho các hệ thống khác để đọc dữ liệu từ KYC.

Hyperledger Fabric Blockchain

• Công nghệ sổ cái phân tán được sử dụng để can thiệp vào quy trình eKYC. Các tính năng nhất định trong quy trình KYC sẽ được thực hiện và lưu trữ trên chuỗi (chain).

Hàm băm cho các tài liệu có liên quan tới KYC

• Bằng chứng để ngăn chặn can thiệp/chỉnh sửa tài liệu.

Nhà cung cấp chứng minh số

• Cung cấp và quản lý quyền của những đối tượng trong blockchain.

Dịch vụ Ordering

• Xác minh quyền của các đối tượng trong các mạng blockchain.

IaaS/PaaS – Microsoft Azure

• Một nền tảng kiêm mô hình tiện ích tiêu dùng của hạ tầng máy tính, được cung cấp bởi Microsoft.

An ninh mạng

• Quy chuẩn về an ninh sẽ được gắn vào trong kiến trúc và thiết kế

Hiểu được về sự tương tác giữa các thành phần công nghệ với biểu đồ dòng thông tin, trong đó, các biểu đồ dòng thông tin sẽ giúp người đọc hiểu được tương tác trong lớp công nghệ, từ đó đưa ra được các tính năng giải pháp mấu chốt.

“Chuyện gì xảy ra giữa các lớp công nghệ khi onboard một khách hàng mới?”

Hệ thống eKYC cũng sẽ chỉ ra và xử lý các API từ hệ thống bên ngoài hoặc API đến từ bên thứ 3.

Lợi ích và Giá trị

• Mang lại tính tài chính toàn diện hơn;
• Xử lý các vấn đề giảm thiểu rủi ro;
• Giảm chênh lệch dữ liệu trong quá trình onboard cho SME;
• Cấp quyền cho FI và các đơn vị liên quan khác, qua đó tăng hiệu quả, đạt lợi ích;
• Giảm chi phí onboard khách hàng.

Case Study: LMS – Loyalty Management System (Hệ thống quản lý khách hàng thân thiết)

Khách hàng của FPT là một trong các công ty dịch vụ chuyên môn hàng đầu thế giới, với ba dòng dịch vụ chính là thuế, kiểm toán, và tư vấn cho rất nhiều lĩnh vực khác nhau.

Nhu cầu của khách hàng

Về cơ bản, dự án yêu cầu xây dựng một hệ thông quản lý khách hàng thân thiết, bao gồm ba câu chuyện người dùng như sau:

• Onboard cho bên thứ 3 mới;
• Hoàn lại từ các chương trình tích điểm của nhiều bên thứ 3 khác từ quy trình đặt vé cho khách hàng;
• Tự động hoàn lại khi bán cho bên thứ 3.

Giải pháp

Trách nhiệm của FPT là khai triển và phát triển nền tảng Blockchain. Dự án bao gồm việc pháp triển một hệ thống cho phép thành viên sử dụng số dặm bay để tiêu dùng tại các cơ sở bán lẻ, khách sạn, trạm xăng, cùng một số dịch vụ thương mại khác.

Các thành phần kỹ thuật có liên quan trong xây dựng phiên bản thử là:

• Nền tảng Ethereum: Dùng để quản lý điểm thưởng của khách hàng trong sổ cái phân tán.
• Simulated Desktop Site (trang Desktop mô phỏng): Để mô phỏng trang đặt vé máy bay, cơ chế tích dặm bay, là đổi Điểm thưởng.
• Tích hợp API: Để tích hợp với hệ thống quản lý khách hàng thân thiết của khách hàng (môi trường kiểm thử). Các kết nối API sẽ được cung cấp bởi khách hàng.

Thành phần	Technical Stack	Mô tả
Blockchain	Ethereum	Nền tảng blockchain riêng tư được sử dụng để hỗ trợ các giải pháp quản lý khách hàng thân thiết như tích lũy, chuyển đổi, và sử dụng điểm thưởng. Phát triển hợp đồng thông minh cho cơ chế đổi dặm bay và điểm thưởng bằng ngôn ngữ lập trình Solidity.
Storage	MySQL	Các lưu trữ dữ liệu off-chain, cần thiết cho việc lưu các thông tin về người dùng, vai trò, dữ liệu tham khảo, thông số cấu hình… thông thường sẽ phải có trong ứng dụng phân tán.
Back End	Node.js, Express.js, web3.js	Node.js với mã nguồn mở và nền tảng SDK được sử dụng cho cấu hình với tính năng thông minh. Các công nghệ dựa trên nền tảng Node.js mở được sử dụng để phát triển tích hợp API/REST, cũng như xử lý API cho các giải pháp quản lý khách hàng thân thiết.
Frontend	Angular.js	Giao diện người dùng thực hiện việc chuyển đổi và tiêu dùng điểm tích lũy.
Infra	Azure	Cấu trúc liên kết triển khai Azure trong cải thiện khả năng quy mô hóa và tính chắc chắn cho các node và mạng blockchain Ethereum, lớp API, và Dapp. Tất cả sẽ được host trong môi trường cloud.

Lợi ích và giá trị

• Tạo một phương thức sử dụng điểm thưởng mới cho khách hàng;
• Giúp hãng hàng không giảm lượng hàng tồn kho;
• Thông tin không được lưu trữ tại một ví trí, do Blockchain là công nghệ phi tập trung. Vì vậy, mọi đối tác trên mạng đều sẽ nhận được những thông tin giống nhau từ phát sinh giao dịch;
• An ninh tốt hơn: kể cả khi kết nối mạng có vấn đề, các thông tin khách hàng và số dặm bay sẽ vẫn được bảo toàn;
• Công nghệ Blockchain giúp phê duyệt tức thì các yêu cầu chuyển điểm, đồng thời ngay lập tức cập nhật các thay đổi này lên hệ thống.
  Nguồn :http://www.giaosucan.com/2020/02/blockchain-suc-manh-cua-nen-cong-nghiep.html

Kiến trúc Database trong ứng dụng Multi-Tenant

CHUYỆN NGHỀ

Bàn về kiến trúc Database trong ứng dụng Multi-Tenant

16/01/2020

Gần đây mình tham gia phát triển một dịch vụ kiểu Multi-tenant Software as a Service nên cũng dành khá nhiều thời gian tìm hiểu cách thiết kế DB cho nó. Theo nhận định chủ quan thì kiểu ứng dụng này thời gian tới sẽ ngày càng phổ biến. Thực tế lâu nay đã có khá nhiều phần mềm web based theo kiểu multitenancy này rồi.

Để có cái nhìn tổng quan về multi-tenant, giờ hãy tưởng tượng bạn có một web app, bạn muốn bán nó cho vài công ty khác cùng sử dụng và đóng logo của họ lên đó. Cách cài đặt đơn giản nhất là copy thành nhiều bản sao, mỗi ông dùng một bản độc lập nhau. Cứ có khách hàng mới là lại copy cả code, cà database ra rồi cài riêng cho ông khách đó, trên 1 hay nhiều server tùy bạn. Vấn đề nảy sinh khi bạn cần update hay sửa lỗi gì gì đó, bạn sẽ phải xử lý trên từng bản sao, cho từng khách hàng một. Công việc update đó lặp đi lặp lại, càng nhiều khách thì càng nhàm chán và dễ sai sót. Đến lúc này thì bạn nên cân nhắc biến ứng dụng SaaS của mình thành dạng multi-tenant.

Multi-tenancy nghĩa là có nhiều tenant (khách thuê – có thể là công ty, tổ chức) với nhiều user sẽ cùng sử dụng phần mềm của bạn. Khi làm app multi tenant, bạn chỉ triển khai nó một lần chứ không phải là sao chép ra một mớ. Bạn có thể update app một phát cho cả đám tenant và việc triển khai dịch vụ cũng đơn giản hơn. Nói chung multi tenant bây giờ thành xu thế rồi, chả tránh được. Ngày xưa làm phần mềm ra xong đem cài lên máy của khách rồi chạy đi chạy lại bảo trì, càng lắm khách thì càng chạy nhiều. Rồi đến lúc chuyển lên web, thì sao ra cho mỗi ông 1 virtual host hoặc server riêng, không phải chạy nhưng quản lý cũng mệt chả kém. Bây giờ làm kiểu multi tenant thì có thể chỉ cần deploy 1 lần lên 1 đám server, nhưng làm DB, code kiếc lại thêm phức tạp.

Phức tạp là vì tất cả khách cùng chạy chung server, chung code, có thể chung cả DB. Vậy làm sao để đảm bảo cô lập dữ liệu các khách hàng với nhau? Cứ chạy riêng rẽ như xưa thì dễ rồi, ông nào biết ông đấy thôi! Bài viết này mình sẽ giới thiệu 3 cách thiết kế Database – thành phần quan trọng nhất – mà mình lượm lặt được từ Internet. Phần này sẽ chỉ nói về cách thiết kế DB, code sẽ được giới thiệu trong các bài tiếp theo.

Thiết kế cơ sở dữ liệu cho Multi-Tenant SaaS Application

Như đã đề cập, Database là thành phần quan trọng nhất trong kiến trúc multi-tenant. Có 3 vấn đề cần quan tâm khi thiết kế DB:

• Mức độ cô lập dữ liệu (tenant data isolation)
• Khả năng sao lưu và phục hồi từng tenant
• Khả năng mã hóa dữ liệu tenant

Bạn có thể chọn 1 trong 3 cách sau để xây dựng DB cho ứng dụng của mình.

1. Mỗi tenant dùng một database riêng biệt.
2. Dùng chung database nhưng chia cho mỗi tenant một schema riêng hoặc table riêng (nếu DB bạn chọn không có schema).
3. Dùng chung tất, cả database lẫn schema hay table

Giờ chúng ta sẽ bàn chi tiết từng thiết kế.

Mỗi Tenant một Database

Ưu điểm lớn nhất của cách làm này là đảm bảo mức độ an toàn dữ liệu cao nhất cho từng tenant. Database được cô lập ở mức tối đa, nếu cần có thể đặt trên các server khác nhau, do đó tenant này không thể truy cập được dữ liệu của tenant khác.

Ưu điểm thứ hai là tính linh hoạt. Thử nghĩ coi, dữ liệu của doanh nghiệp chính là tài sản, bạn nắm giữ tài sản của họ. Nếu tenant nào đó muốn bạn mã hóa dữ liệu (để tránh rò rỉ do bạn bị tấn công hoặc do nhân viên của bạn lấy đi), trong khi người khác lại không có nhu cầu. Bạn sẽ không tốn chi phí để mã hóa toàn bộ, chỉ cần thực hiện trên tenant cụ thể vì chúng đã hoàn toàn độc lập với nhau.

Việc độc lập database cũng giúp việc sao lưu và phục hồi dữ liệu dễ dàng hơn bao giờ hết. Bạn có thể backup riêng tenant db hàng ngày thậm chí hàng giờ, tùy thuộc gói dịch vụ mà khách hàng đã mua, khi cần thì restore quá sức dễ dàng.

Với chừng ấy lợi ích thì nghe có vẻ đây là giải pháp ngon ăn. Nhưng giả sử bạn không có khách hàng nào VIP đến độ cần mã hóa và backup hàng giờ, thì việc triển khai này lại trở nên tốn kém. Cứ cho là dữ liệu còn bé, có thể chạy chung DB server, nhưng nó vẫn bới thêm công việc quản trị, vận hành…

Nhìn chung đây là một cách làm tốn kém, chỉ phù hợp nếu tập khách hàng có yêu cầu đặc biệt và sẵn sàng chịu chi. Giờ chúng ta nói về phương án rẻ hơn mà vẫn đảm bảo một phần tính cô lập dữ liệu: Mỗi Tenant một Schema riêng.

Mỗi Tenant một Schema

Cách làm này giảm đáng kể chi phí, app của bạn sẽ chỉ kết nối đến 1 Database duy nhất. Mỗi tenant sẽ có một schema riêng (với các table cần thiết) thay vì dùng cả database. Với những DBMS không hỗ trợ multi schema, bạn có thể triển khai bằng cách đặt tên table kèm theo tiền tố để phân biệt các tenant (VD: tenantA_product, tenantA_order…). Bằng cách này bạn có thể giảm bớt chi phí quản trị hoặc duy trì server.

Nhược điểm của thiết kế này là vấn đề backup – restore. Nếu nếu cần restore riêng 1 tenant mà DBMS không hỗ trợ restore từng schema, bạn sẽ phải restore toàn bộ DB, những người khác sẽ bị ảnh hưởng bởi downtime. Và để tránh việc restore ghi đè cả DB, bạn sẽ có nhiều việc cần phải làm! Chẳng hạn như restore vào 1 DB khác, lấy dữ liệu của schema cần xử lý ra, rồi bưng phần này vào DB đang chạy. Nghe thế chứ làm thật chưa chắc đã dễ!

Việc tách schema chỉ đảm bảo được một phần tính cô lập dữ liệu khách hàng nhưng là phương án rẻ hơn tách database. Cá nhân tôi thấy thiết kế này cực kì hợp lý, cân bằng giữa lợi ích, chi phí và độ phức tạp. Bây giờ ta chuyển qua cách thứ 3: Nhồi hết vào 1 chỗ!

Dùng chung Schema cho tất cả Tenant

Nếu bạn chọn DBMS không có schema thì tất cả sẽ dùng chung database. Cách này rất dễ triển khai, ít nhất là trong giai đoạn đầu của dự án, hoặc ở thời điềm mà bạn còn chưa từng nghĩ sẽ làm multi tenant! Vì dữ liệu của tất cả tenant sẽ được lưu trong cùng 1 bảng, bạn có thể chỉ cần thêm vào 1 trường để phân biệt tenant là đủ (như tenant_id chẳng hạn).

Làm kiểu này cũng có cái hay. Bạn không cần phải tạo schema rồi khởi tạo các table cho từng tenant, không cần lo quản lý schema nào của tenant nào, cũng chả phải can thiệp gì vào database.

Thế còn cái dở của mô hình này? Giờ nếu bạn làm ăn tốt, khách hàng tăng trưởng từng ngày, dữ liệu cũng tăng theo. Khi đó table của bạn sẽ ngày càng to ra, việc thao tác trên dữ liệu sẽ dần trở nên khó khăn và chậm chạp. Oái oăm là có những tenant ít dữ liệu lại chịu chung cảnh rùa bò với những thằng to. Điều này đem lại trải nghiệm không hay ho gì. Có nhiều cách để cải thiện hiệu năng nhưng dù sao cái gì cũng có giới hạn của nó. Đến lúc bạn sẽ phải tách vài ông to to ra chạy DB khác. Cũng không sao, miễn là giải quyết được vấn đề! Chỉ có điều việc lọc lấy dữ liệu để tách ra không phải một sớm một chiều mà xong ngay được, trong khi downtime thì có hạn! Lại còn cả vấn đề backup – restore nữa.

Túm lại thì thiết kế nào cũng có cái hay và cái rắc rối của nó. Bạn nên xem xét thấu đáo từng khía cạnh và đặt lên bàn cân để đưa ra lựa chọn cho riêng mình. Theo tôi đánh giá thì cách chia Schema là cân bằng nhất giữa mức độ an toàn, độ phức tạp khi triển khai và chi phí vận hàng database, tôi cũng đã chọn cách này cho vài dự án của mình. Còn bạn, bạn chọn phương án nào? Hoặc nếu cần thảo luận thêm, hãy để lại comment vì những điều trên chắc là chưa đủ.

How to Find Your Goals

Ref : https://possibilitychange.com/how-to-find-your-goals/

There’s a lot of information out there about how to achieve your goals. About how to stay motivated, how to focus on your dreams and not be distracted by failure and set backs. But that all assumes that you know what you want out of life, that you already have goals you’re eager to achieve. Recently, in response to a comment I made about pursuing one’s goals on The Change Blog, I got a poignant reply that asked “But what if you haven’t found anything worth doing, any goal worth pursuing?”
Great question – focus is wonderful, but if we aren’t looking at the right things how useful is it? Sure we can learn from failure, but what do we do with those lessons if we’re not really doing anything? How can we find out where we should be looking for our satisfaction in life?

Step 1 – Make a list of what’s important to you.

Do it quickly and without censoring – it’s ok if your list includes your cat or your new shoes. Your choices reflect a snapshot of your life right now and don’t need to be lofty or impressive. Here’s my quick list (in no particular order): my daughter, my friends, writing, coaching, my house, my central heating, my cat, my favorite TV shows (blush), learning, my blog.

Step 2 – Ask “Why is this important?” for each item on your list.

Here are my answers:

• My daughter because she is my contribution to the world at the most basic level and because she’s fun, loving and makes me happy.
• My friends because they support me, teach me, and make me laugh.
• Writing and my blog because they ignite my passion and I feel like I’m able to help people with them. And they’re fun!
• Coaching because I’m helping my clients live better and clearer lives.
• My house because it provides me with a beautiful and safe place to be.
• My central heating because it keeps me warm and comfortable.
• My favorite TV shows because they take me to places where life is silly and adventurous and because they often provide me with a fascinating glimpse into human nature.
• Learning because it makes me a better person and helps me grow.

Step 3 – Use your answers to identify your values.

Look for themes in your answers. When you read over your list, what pops out at you? What shows up more than once? Are there items that have something in common? I see the following themes in my list: contribution, fun & laughter, learning, helping people, comfort.
The themes we identify reflect our values and what’s most important to us in our lives. And this is where goal setting should begin.

Step 4 – Use your values to set your goals.

The goals that inspire you most will be based on your values, on what’s really important to you. You might already be working on some of them – I’ve set clear goals around my writing and am beginning to revamp my coaching practice. But when I look at my list I realize that I’m not putting much effort to making sure that I have enough fun and laughter in my life right now, so I might want to set a goal to find more ways to play.
When you set your goals:

• Make your goals bite-sized – A goal of “Learn the skills I need for my next promotion” sounds achievable, while a goal of “Become CEO by the time I’m 30” is probably going to set you up for failure.
• Make your goals positive – You should work toward what you want, not away from what you don’t want. “I want to find a loving partner” inspires while “I don’t want to be lonely anymore” already feels defeated.
• Realize that as you work toward your goals they’ll probably change – As we learn and grow from the work we do to move toward our goals we often connect with new, more resonant goals. After I set up my coaching practice I started writing newsletters to attract more clients. But I found that I loved writing as much as I loved coaching, and my goal shifted from attracting clients to creating a blog.

The bottom line is that when our goals tap into the beauty and energy of our values they make our hearts sing. They feed our hungers, we can’t wait to get started working on them. So my answer to the reader who asked about finding a goal worth pursuing is that the answer is in your heart, it’s in your longings, it’s in the things you want more of.

Tìm hiểu Domain Driven Design (DDD)

Trong thiết kế kiến trúc Microservice, có thể bạn sẽ được nghe nhiều về thuật ngữ Domain Driven Design, một phương pháp thiết kế phần mềm theo hướng business domain. Phương pháp này được giới thiệu bởi Eric Evan, viết thành một cuốn sách dày cộp bán trên Amazon, mình đã đọc cuốn sách này cả phiên bản tiếng Anh và tiếng Việt. Tuy nhiên câu từ trong cuốn này xác cmnd là éo hiểu gì, chữ viết như giun bò, kiến chạy, dài dòng lê thê, có lẽ cỡ như Bill Gate mới hiểu được.

Thế rồi một đêm xem xvideo, lướt vài vòng webtretho nghe các mẹ tâm sự chuyện tâm sinh lý, mình mới chợt ngộ ra bí ẩn trong cuốn sách của Eric Evan, quả là một bầu trời kiến thức, bài viết này sẽ mô tả lại phương pháp này một cách giản đơn, để cỡ như JAV idol như Yuina Hatano cũng hiểu được

Vì sao lại đẻ ra DDD (Domain Driven Design)

Giả sử một anh dev được giao nhiệm vụ phát triển một ứng dụng bán hàng online. Thanh niên coder thì sẽ áp dụng mô hình quen thuộc MVC hay MVVM

Nhìn source code thì kiểu thế này

OK, cool, tuy nhiên đem cấu trúc này cho một BA (Business Analysis) thì anh ta lại không hiểu controller, view là cái giề. Anh ấy chỉ biết về nghiệp vụ bán hàng, order online, thanh toán thì đi theo flow abc, xyz. Còn chú coder thì biết mỗi Java, .NET design pattern. Kiểu nhưng 1 anh tàu nói tiếng Chinese với 1 anh US. Như vậy phải có 1 phương pháp nào đó để anh dev và anh BA có thể ngồi được với nhau sử dụng 1 ngôn ngữ chung để cả 2 có thể hiểu, và Domain Driven Design ra đời.

DDD là gì

DDD không phải là công nghệ gì cả, nó là một design pattern, một phương pháp thiết kế phần mềm, nhìn trên góc độ architect. Trong đó ứng dụng sẽ được chia thành 4 layer như ở dưới

Đoạn định nghĩa này lấy nguồn trên internet cho nhanh

User  Interface Layer:  làm nhiệm vụ biểu diễn thông tin trực quan cho user và dịch các user command ( ở đây chúng ta có thể hiểu là các event xảy ra trên giao diện khi được trigger ( nhấn nút trên các UI input control ) là các sẽ được dịch thành các command xử lý ở các tầng dưới.

Application Layer: Tầng này được thiết kế khá mỏng ( thin ) với ít logic xử  lý chỉ để làm nhiệm vụ coordinate các Activity của Application và không chứa Business Logic, nó không chứa state của các Business Object mà chỉ chứa state của Application Task Progress. Chúng ta có thể hình dung phần này gần giống với các Controller trong mô hình MVC chỉ làm nhiệm vụ forward các task đến nơi cần xử lý.

Domain Layer: Đây là trái tim của ứng dụng ( Business Software ), các  state của Business Object đều nằm ở đây. Việc lưu trữ ( persistence ) các Business Object và các state của nó được chuyển giao cho tầng Infrastructure ở dưới.

Trái tim của mô hình này chính là ở phần Domain Layer, các nghiệp vụ sẽ được mô tả tại đây, và cấu trúc source code cũng được tổ chức theo tên các nghiệp vụ chứ không để kiểu view, controller như truyền thống

Chẳng hạn như Order App thì chia thành thư mục hướng nghiệp vụ như Buyer, Order… Như vậy anh BA nhìn vào có thể hiểu ngay là app này có chức năng gì

Infrastructure Layer:  Đóng vai trò cung cấp thư viện ( supporting libraries )cho các tầng khác. Nó cung cấp cơ chế giao tiếp ( communication ) giữa các Layer  với nhau, cũng như cung cấp các chức năng khác như lưu trữ ( persistence ) các Business Object của tầng Domain.

Cái tầng Infrastructure Layer dễ làm người đọc lầm lẫn sang hạ tầng phần cứng như máy chủ, database server, nhưng thật ra không phải, do chú tây viết sách thích tỏ ra nguy hiểm. Còn trong DDD, layer này có thể hiểu như tầng common library như logging, utility và phần data persistent layer của tầng Data Access trong mô hình thông thường, tức là vẫn chỉ là phần mềm

DDD vs Mô hình 3 lớp truyền thống

So sánh DDD với mô hình 3 lớp truyền thống có thể ví như cái nhà ống 3 tầng có cấu thang bộ với nhà 4 tầng có thêm thang máy

Mô hình 3 lớp truyền thống, tầng 3 (Presentation) muốn xuống tầng 1 (Data Tier) phải qua tầng 2 Business Tier

Mô hình DDD thì tầng 4 (UI) muốn xuống tầng 1 (Persistence) có thể qua thang máy là (Infrastructure) để xuống luôn cho nhanh, có muốn tập thể dục thì đi tuần tự từng tầng như truyền thống.

Thuật ngữ trong DDD

Mỗi lĩnh vực (domain) trong cuộc sống đều có thuật ngữ khác nhau. Dramma hàn quốc thì có thuật ngữ như uppa, ung thư. Kiếm hiệp Hoa Ngữ thì có tuyệt chiêu, bí kíp, kiếm pháp. Chính trị thì có tư tưởng HCM, lý luận Đặng Tiểu Bình, cách mạng, đường lối chính sách. DDD cũng có những thuật ngữ riêng như Entity, Value Object, Aggregate vân vân và mây mây. Cuốn sách của Evic giải thích thì vô cùng khó hiểu. Tuy nhiên giaosucan’s blog sẽ giải thích dần dần cho các bạn những thuật ngữ này theo cách đơn giản nhất trong các phần sau…

Source Link: http://www.giaosucan.com/2018/08/hieu-domain-design-theo-cach-ba-ao-part.html