Trong bài viết trước của chúng tôi, " Chìa khóa chiến thắng trong hệ sinh thái AO: Kiến trúc microservice trong kỷ nguyên Web3 ", chúng tôi đã thảo luận về những ưu điểm của mô hình Actor và mức độ phức tạp mà nó mang lại cho việc phát triển ứng dụng. Để giải quyết "sự phức tạp", các nhà phát triển Web3 cần tiếp tục học hỏi từ Web2, vốn đã đạt được "sự áp dụng đại trà", bao gồm các phương pháp phát triển, công cụ phát triển và thực tiễn công nghệ phần mềm. Bài viết tiếp theo thảo luận về một trong những cách khả thi, đó là tăng cường đầu tư vào "nền tảng phát triển mã thấp" và chuyển một phần đáng kể tính "phức tạp" của việc phát triển ứng dụng sang nền tảng mã thấp, để các nhà phát triển ứng dụng có thể tập trung hơn vào logic kinh doanh.

Tác giả: Yang Jiefeng @ArweaveOasis

Người đánh giá: chanh

Nguồn: Hiệp hội nội dung - Tin tức

Trong bài viết trước, " Chìa khóa chiến thắng trong hệ sinh thái AO: Kiến trúc microservice trong kỷ nguyên Web3 ", chúng tôi đã thảo luận về những lợi thế của việc áp dụng kiến ​​trúc microservice (hoặc mô hình Actor) và mức độ phức tạp mà nó mang lại cho việc phát triển ứng dụng. Đồng thời, ở phần cuối có đề cập rằng cuộc chiến giành chuỗi công cộng thực sự là cuộc chiến dành cho các nhà phát triển ứng dụng. Vì vậy, trong một chuỗi công khai cạnh tranh khốc liệt như vậy, làm thế nào AO có thể giành chiến thắng trước các nhà phát triển?

Tất nhiên, hãy tiếp tục học hỏi từ Web2, web đã đạt được "sự áp dụng hàng loạt". Điều này không chỉ bao gồm việc tìm hiểu cơ sở hạ tầng của nó mà còn bao gồm các khía cạnh như phương pháp phát triển, công cụ phát triển và thực tiễn công nghệ phần mềm.

Nền tảng phát triển low-code chắc chắn là một hướng đi đáng được đầu tư mạnh mẽ trong lĩnh vực Web3. Ý tôi là chúng ta có thể chuyển một phần đáng kể tính "phức tạp" của việc phát triển ứng dụng sang các nền tảng mã thấp.

Nền tảng phát triển mã thấp là gì?

Đầu tiên mình muốn làm rõ sự khác biệt giữa Low-Code (low code) và No-Code (no code) - tất nhiên đây chỉ là ý kiến ​​cá nhân của mình thôi:

Mã thấp VS Không mã

Vậy “tiêu chuẩn thực tế” cho nền tảng mã thấp mà tôi đang nói đến là gì? Bạn có thể tham khảo lời giải tại đây .

Bạn có thể đã nghe nói về nền tảng mã ngắn “theo hướng biểu mẫu” hoặc nền tảng mã ngắn “theo hướng bảng”, nhưng ở đây, tôi đặc biệt đề cập đến nền tảng mã thấp “theo mô hình”. Bạn có thể hiểu mô tả của tôi là một cách hiểu hẹp về khái niệm "nền tảng mã thấp".

Nền tảng phát triển mã thấp cho các ứng dụng truyền thống đã bước vào giai đoạn trưởng thành ban đầu. Ai đó có thể nói: "Dường như tôi chưa từng nghe nói đến nền tảng phát triển mã thấp Web3 'theo mô hình'." Thật vậy, đây là một điều tương đối hiếm. Hãy phân tích tại sao.

Trước hết, tại sao các nền tảng low-code truyền thống vẫn chưa bước vào không gian Web3? Tôi nghĩ chủ yếu là do mô hình mô hình hóa mà họ sử dụng không áp dụng cho Web3.

Nền tảng doanh nghiệp truyền thống sử dụng mô hình ER và/hoặc mô hình quan hệ. Ví dụ: OutSystems sử dụng cả mô hình ER và mô hình quan hệ; một số nền tảng chỉ sử dụng cái này hoặc cái kia. Mô hình ER và mô hình quan hệ giống nhau về mặt khái niệm. Các nền tảng này tạo mã có thể chạy trên cơ sở hạ tầng phần mềm doanh nghiệp truyền thống như cơ sở dữ liệu SQL. Nhưng chúng khó chạy trên cơ sở hạ tầng Web3 như blockchain vì “sổ cái phi tập trung” trên blockchain quá khác với cơ sở dữ liệu SQL.

Vậy, “nền tảng mã thấp” hiện có dành cho các ứng dụng phi tập trung hoạt động như thế nào?

Phát triển một nền tảng mã nguồn ngắn thực sự—đặc biệt với cách tiếp cận dựa trên mô hình—không phải là nhiệm vụ dễ dàng. Một số người có thể bị cám dỗ để né tránh nhiệm vụ khó khăn này. Tuy nhiên, chức năng cốt lõi của nền tảng low-code chuyên nghiệp mang lại giá trị độc đáo mà không giải pháp nào khác có thể sánh được. Ví dụ: "mẫu hợp đồng thông minh có thể định cấu hình" có thể giúp nhà phát triển sao chép "mã tạo sẵn" nhanh hơn, nhưng đối với những ứng dụng đổi mới đó, các mẫu này không được sử dụng nhiều. Đây cũng là một thách thức lớn đối với các nhà phát triển nền tảng trong việc viết và duy trì một thư viện "mẫu hợp đồng thông minh" phù hợp cho nhiều chuỗi bằng các ngôn ngữ khác nhau (chẳng hạn như Solidity, Move, v.v.). Hơn nữa, “hợp đồng thông minh” chỉ là phần trên chuỗi của ứng dụng và các ứng dụng phi tập trung lớn hơn một chút cũng thường yêu cầu các phần ngoài chuỗi.

dddappp: Nền tảng phát triển mã thấp Web3 đích thực

Vì vậy, liệu có một nền tảng phát triển mã nguồn ngắn Web3 “thực sự”—áp dụng cách tiếp cận “dựa trên mô hình” mà không giở thủ đoạn và đối mặt trực tiếp với thử thách không?

Tôi rất tự hào thông báo rằng dddappp do nhóm của tôi phát triển là một nền tảng phát triển mã nguồn ngắn thực sự cho các ứng dụng phi tập trung. Đây có lẽ là nền tảng phát triển mã thấp Web3 duy nhất hiện đang áp dụng cách tiếp cận "dựa trên mô hình".

Vậy dddappp có gì độc đáo đến vậy? Tại sao nó có thể làm được điều mà không nền tảng nào khác có thể làm được (ít nhất là tạm thời)?

Điều quan trọng là mô hình mô hình được dddappp áp dụng. Chúng tôi đã chọn mô hình miền kiểu DDD.

Mô hình miền kiểu DDD là mô hình OO (hướng đối tượng) trừu tượng ở mức độ tương đối cao. Các công cụ tự động hóa có thể dễ dàng ánh xạ các mô hình miền cấp cao đó sang các mô hình triển khai cấp thấp, chẳng hạn như mô hình lập trình hướng đối tượng, mô hình dữ liệu quan hệ, v.v.

"trừu tượng cấp cao" là gì? Hãy nói theo cách này, nó giúp bạn thể hiện càng nhiều càng tốt “những gì” bạn biết về lĩnh vực này, thay vì “làm thế nào” để giải quyết vấn đề một cách chi tiết kỹ thuật.

Các nhà phát triển có kinh nghiệm sẽ hiểu ngay rằng điều này nói dễ hơn làm. Chúng tôi có thể làm điều này hoàn toàn một cách tình cờ và chúng tôi đã tích lũy được kinh nghiệm phong phú trong lĩnh vực này - chúng tôi đã làm việc này từ năm 2016. Chúng tôi thậm chí còn viết một cuốn sách để chia sẻ kinh nghiệm của mình với các nhà phát triển.

Các nhà phát triển có kinh nghiệm sẽ hiểu ngay rằng điều này nói dễ hơn làm. Chúng tôi có thể làm điều này hoàn toàn một cách tình cờ và chúng tôi đã tích lũy được kinh nghiệm phong phú trong lĩnh vực này - chúng tôi đã làm việc này từ năm 2016. Chúng tôi thậm chí còn viết một cuốn sách để chia sẻ kinh nghiệm của mình với các nhà phát triển.

Điều quan trọng là chúng tôi đã phát minh ra một DSL rất biểu cảm để lập mô hình miền có tên là DDDML (từ viết tắt của Ngôn ngữ mô hình hóa thiết kế hướng miền). Sử dụng nó, không chỉ kiến ​​thức về miền có thể được mô tả chính xác mà những mô hình này còn có thể dễ dàng ánh xạ vào mã triển khai phần mềm.

Nhân tiện, DSL của chúng tôi gần với miền vấn đề và ngôn ngữ tự nhiên hơn so với các "đối thủ cạnh tranh" khác, điều mà chúng tôi tin rằng khiến nó được tích hợp hoàn hảo với trí tuệ nhân tạo (AI).

Bản thân chúng tôi luôn gọi DDDML là "DDD DSL gốc".

Bạn có nhớ khái niệm "tổng hợp" từ DDD mà tôi đã đề cập trước đó không? DSL chúng tôi sử dụng hỗ trợ xác định các tập hợp ngay từ đầu. Khi bạn mở bất kỳ tệp mô hình DDDML nào, bạn gần như có thể thấy các tập hợp từ khóa.

Nếu bạn đã quen thuộc với các khái niệm liên quan đến DDD, bạn sẽ dễ dàng hiểu được mô hình được mô tả bởi DDDML, nếu bạn không quen với nó thì DDD có cả những cuộc thảo luận có hệ thống trong các tác phẩm cổ điển và cách thực hành của những người hâm mộ theo kịp. với thời đại, chỉ cần bạn sẵn sàng “nắm bắt” thì chúng gần như nằm trong tầm tay bạn.

Nền tảng vững chắc của phương pháp DDD thường làm chúng tôi ngạc nhiên. Khi chúng tôi phát triển các ứng dụng truyền thống (phần phụ trợ chủ yếu được viết bằng Java hoặc C#), chúng tôi đã sử dụng phương pháp "hướng mô hình miền", giúp cải thiện đáng kể hiệu quả phát triển. Khi bước vào thế giới mới của Web3, chúng tôi nhận thấy rằng chúng tôi có thể sử dụng DDDML để thúc đẩy sự phát triển của các ứng dụng phi tập trung mà không cần thêm quá nhiều thứ vào đó.

Dddappp giúp phát triển ứng dụng sinh thái AO như thế nào?

Trong nửa đầu của bài viết này, chúng tôi đã nói về một số thách thức khi phát triển ứng dụng bằng AO.

Vậy giải pháp kỹ thuật được dddappp áp dụng có thực sự giúp ích được cho các nhà phát triển trong hệ sinh thái AO không? Hãy xem bằng chứng khái niệm mà chúng tôi đã hoàn thành gần đây dựa trên AO .

Trong phần trình diễn này, chúng tôi tin rằng chúng tôi đã cung cấp các giải pháp rất hấp dẫn cho một số vấn đề. Chúng tôi đã trình bày cách sử dụng DSL để xác định các tập hợp, đối tượng giá trị và dịch vụ (đây là các khái niệm về DDD) và cho thấy hình thức chung của mã được tạo. Bạn có thể tưởng tượng nếu các nhà phát triển thực sự sẵn sàng viết mã này bằng tay mà không cần sử dụng công cụ không? Đặc biệt, chúng tôi cũng chứng minh cách mã được tạo có thể triển khai xử lý "tính nhất quán cuối cùng" một cách tinh tế bằng cách sử dụng mẫu SAGA .

Chúng tôi gọi cuộc trình diễn này là PoC, nhưng thực ra tôi nghĩ nó vượt xa PoC. Bởi vì nó có thể giúp ích ngay lập tức cho các nhà phát triển trong hệ sinh thái AO. Các nhà phát triển trong hệ sinh thái AO hiện có thể sử dụng nó để làm rõ các ý tưởng thiết kế ứng dụng, tạo mã (ít nhất những mã này có thể được sử dụng làm tài liệu tham khảo triển khai) và nâng cao hiệu quả. Ở một mức độ nào đó, bạn có thể nói rằng công cụ này là MVP (sản phẩm khả thi tối thiểu). Bởi vì định nghĩa của MVP là miễn là nó có thể giúp ích cho người dùng cuối và có giá trị đối với người dùng cuối thì nó có thể được gọi là MVP. Xét cho cùng, các nhà phát triển là người dùng cuối của các công cụ mã nguồn thấp.

Nếu các nhà phát triển ứng dụng có kinh nghiệm nghiên cứu kỹ PoC này, họ có mọi lý do để không còn nghi ngờ về tiềm năng to lớn của các phương pháp low-code trong việc cải thiện hiệu quả phát triển ứng dụng. Suy cho cùng, chúng tôi đã chứng minh điều này nhiều lần bên ngoài hệ sinh thái AO. Ngay cả khi không đề cập đến các ứng dụng thương mại phức tạp mà chúng tôi đã phát triển bằng phương pháp tương tự trong kỷ nguyên Web2, chỉ cần quan sát các hoạt động của chúng tôi trong hệ sinh thái Move là đủ thuyết phục.

Chúng tôi sử dụng DSL để giải quyết hạn chế của Move (ngôn ngữ hợp đồng thông minh tĩnh) thiếu tính trừu tượng về "giao diện" và giúp các nhà phát triển dễ dàng triển khai "chèn phụ thuộc".

Chúng ta có thể chia hợp đồng Move thành nhiều gói (tức là "dự án") bằng một khai báo đơn giản, xem ví dụ này . Cần lưu ý rằng hầu hết các chuỗi công khai Move đều có giới hạn về kích thước của mỗi gói được phát hành.

Nếu bạn đang nghĩ rằng những gì chúng tôi đang chia sẻ chỉ là một số “ví dụ” và có thể chúng tôi chỉ đang làm một số đồ chơi thì bạn đã nhầm to rồi.

Nếu bạn đang nghĩ rằng những gì chúng tôi đang chia sẻ chỉ là một số “ví dụ” và rằng chúng tôi có thể chỉ đang làm một số đồ chơi thì bạn đã nhầm to rồi.

Chúng tôi đã tham gia sâu vào quá trình phát triển một số ứng dụng thương mại nghiêm túc (chủ yếu tập trung vào hệ sinh thái Move). Trong quá trình này, chúng tôi gần như đã "ăn thức ăn cho chó của chính mình". Chúng tôi có thể tự tin nói rằng hiện tại, ít nhất là trong khu vực phát triển back-end (tôi đề cập đến hợp đồng trên chuỗi và dịch vụ truy vấn ngoài chuỗi, sau này đôi khi được gọi là người lập chỉ mục), chúng tôi đã thực hiện lời hứa của mình về 10 lần hiệu quả phát triển.

Chúng tôi thậm chí còn phát triển các ứng dụng "không có mã" dựa trên "mã thấp" (một lần nữa: công cụ không có mã là ứng dụng dành cho người dùng cuối). Chúng tôi đã xây dựng một sản phẩm phụ có tên Move Forms tại Aptos Singapore Hackathon, sản phẩm này đã giành vị trí thứ hai trong phiên bản hiện tại. Chúng tôi sẽ tiếp tục xây dựng công cụ biểu mẫu gốc Web3 này trong thời gian rảnh rỗi.

Nếu bạn liên hệ với chúng tôi, chúng tôi có thể hiển thị cho bạn nhiều trường hợp ở cấp độ sản xuất hơn. Các trường hợp của chúng tôi bao gồm mạng xã hội, DeFi, trò chơi toàn chuỗi, v.v.

Nhiều người có thể đặt câu hỏi về các loại ứng dụng phi tập trung có thể được phát triển bằng nền tảng mã nguồn thấp. Thành thật mà nói, chúng tôi chưa tìm thấy bất kỳ hạn chế rõ ràng nào đối với các loại ứng dụng có thể được phát triển bằng phương pháp mã thấp. Trong quá trình phát triển ứng dụng, điều chúng tôi cảm nhận sâu sắc hơn là những hạn chế của cơ sở hạ tầng Web3 hiện tại, hơn là những hạn chế của low-code.

Tôi không biết bạn có phát hiện ra một thực tế thú vị hay không, đó là các nền tảng low-code truyền thống thường được coi là phù hợp hơn để phát triển phần mềm doanh nghiệp (chẳng hạn như OA, CRM, ERP, v.v.) và không phù hợp để phát triển các ứng dụng Internet nhưng từ những gì chúng tôi đã trình bày, có vẻ như dddappp đã vượt quá giới hạn này? Cảm giác của bạn là đúng. Lý do tại sao chúng tôi muốn làm điều này trong kỷ nguyên Web2 - một nền tảng mã thấp được điều khiển bởi mô hình miền DDD, một nỗ lực rất táo bạo trong kỷ nguyên Web2, là để "cho phép nền tảng mã thấp phát triển quy mô lớn". ứng dụng Internet."

“AppCU” có thể là bước đột phá trong việc mở ra hệ sinh thái AO

Mặc dù sự kết hợp giữa Lua và WASM rất tốt, nhưng thành thật mà nói, trong ngắn hạn, tôi không thể tưởng tượng việc dựa vào chúng để tích hợp các ứng dụng Internet Web2 quy mô lớn (như Amazon, Taobao, v.v.) vốn truyền thống được viết bằng Java, C#, PHP, Python, v.v., eBay, Shopee, v.v.) đã chuyển sang AO.

Như đã đề cập trước đó, AO là một giao thức dữ liệu. Về lý thuyết, bất kỳ ai cũng có thể phát triển “sự triển khai” của riêng mình bằng ngôn ngữ lập trình yêu thích và truy cập mạng AO để tương tác và cộng tác với các đơn vị khác.

Trong mạng AO, logic nghiệp vụ của ứng dụng được thực thi trong Đơn vị điện toán. Do đó, đối với các nhà phát triển ứng dụng, điều họ mong muốn nhất là sự đa dạng và hòa nhập hơn trong nền tảng phát triển được hỗ trợ bởi các đơn vị tính toán. Theo những gì tôi biết, cộng đồng nhà phát triển AO đã làm việc theo hướng này, chẳng hạn như hỗ trợ các hợp đồng thông minh EVM chạy trên AO.

Tuy nhiên, tôi nghĩ vấn đề này có thể đột phá theo một hướng khác. Tôi tin rằng AppCU là một ý tưởng hay. AppCU, ý tôi là Đơn vị tính toán dành riêng cho ứng dụng. Một sự tương tự với Appchain ( blockchain dành riêng cho ứng dụng ) sẽ giúp hiểu ý tôi.

Nếu đơn vị tính toán bị loại trừ, ở một mức độ nhất định, các phần khác của AO có thể được coi là phiên bản Web3 của Kafka - một nhà môi giới tin nhắn phi tập trung. Cho phép các nhà phát triển ứng dụng truyền thống sử dụng các ngôn ngữ và công cụ thành thạo của họ để phát triển các ứng dụng kiến ​​trúc microservice dựa trên trình trung chuyển tin nhắn giống Kafka - "Haha, tôi quen với điều này."

Xây dựng AppCU từ đầu có thể không dễ dàng đối với hầu hết các nhà phát triển và việc xây dựng Appchain cũng vậy. Vì vậy, trong trường hợp này, một công cụ tiện dụng là điều cần thiết.

Tôi nghĩ không cần phải nhấn mạnh vai trò quan trọng của Cosmos SDK (công cụ dùng để xây dựng Appchain) trong sự phát triển của hệ sinh thái Cosmos phải không?

Tôi nghĩ không cần phải nhấn mạnh vai trò quan trọng của Cosmos SDK (công cụ dùng để xây dựng Appchain) trong sự phát triển của hệ sinh thái Cosmos phải không?

Các nhà phát triển đã dùng thử Cosmos SDK sẽ rất ấn tượng bởi sự tiện lợi và sức mạnh của công cụ này. Nếu Cosmos SDK làm được thì không có lý do gì mà cộng đồng nhà phát triển hệ sinh thái AO lại không làm được. Trong mọi trường hợp, việc phát triển một đơn vị tính toán luôn dễ dàng hơn so với một chuỗi, phải không?

Cosmos SDK thực sự là một công cụ "hiệu quả cao", nhưng nói đúng ra, nó không phải là một nền tảng mã nguồn thấp. Chúng tôi tin rằng nền tảng mã thấp có tiềm năng lớn hơn để cải thiện hiệu quả phát triển.

AI sẽ thay thế nền tảng low-code?

Cuối cùng, tôi muốn nói về một câu hỏi mà tôi đã trả lời vô số lần: “Liệu AI có giết chết các nền tảng mã nguồn thấp không?”

Theo tôi, những tiến bộ to lớn mà AI đạt được trong những năm gần đây không mang lại bất kỳ thay đổi cơ bản nào trong phương pháp phát triển phần mềm phức tạp. Ngay cả khi AI tham gia vào việc phát triển các ứng dụng phức tạp, nó vẫn phải tuân theo cách tiếp cận “đúng đắn” – giống như con người.

Mọi mức độ trừu tượng trong công nghệ phần mềm đều có giá trị của nó. "Tư thế" đúng đắn đầu tiên để phát triển phần mềm phức tạp là thực hiện phân tích kinh doanh và lập mô hình miền trước. Việc sử dụng ngôn ngữ tự nhiên không thể mô tả chính xác “nhận thức về miền”, điều này cản trở rất lớn đến hiệu quả của việc “chuyển nó thành mã phần mềm”.

Điều độc đáo nhất về dddappp là DSL mà nó sử dụng. Chính nhờ điều này mà dddappp cho phép AI tập trung vào những gì nó làm tốt nhất:

1. AI đề xuất các mô hình tham chiếu và hỗ trợ chúng ta lặp lại mô hình đó.

2. AI hỗ trợ thực hiện “logic kinh doanh vận hành”.

Vì vậy, câu trả lời của tôi cho câu hỏi này là: không. Chúng tôi nghĩ rằng cả hai sẽ bổ sung tốt cho nhau - ít nhất là đối với dddappp.

Tóm lại, chúng tôi đã phân tích định nghĩa về nền tảng phát triển mã nguồn thấp và tiềm năng to lớn của nó trong việc giảm bớt sự phức tạp trong quá trình phát triển ứng dụng Web3. Dựa trên khái niệm nền tảng low-code, chúng ta có thể xây dựng một công cụ mạnh mẽ tương tự Cosmos SDK (công cụ dùng để xây dựng Appchain trong hệ sinh thái Cosmos) trong hệ sinh thái AO và sử dụng công cụ này để xây dựng AppCU, có thể giảm thời gian phát triển của các nhà phát triển. Sự phức tạp cũng mở ra những ý tưởng và khả năng mới để hệ sinh thái AO đạt được sự áp dụng trên quy mô lớn.

🏆 Giải “bắt lỗi”: Nếu phát hiện lỗi chính tả, câu sai hoặc mô tả sai trong bài viết này, hãy bấm vào để tôi báo cáo và bạn sẽ nhận được ưu đãi.

Tuyên bố miễn trừ trách nhiệm: Bài viết này không thể hiện quan điểm hoặc quan điểm của PermaDAO. PermaDAO không cung cấp lời khuyên đầu tư hoặc chứng thực bất kỳ dự án nào. Người đọc được yêu cầu tuân thủ luật pháp của quốc gia nơi họ sinh sống và thực hiện các hoạt động Web3 theo đúng quy định.

🔗 Giới thiệu về PermaDAO: Trang web Twitter Telegram |