#123 - Những điều bạn cần biết về Domain-Driven Design

May 31, 2020

Grokking Webinar #05 về chủ để Engineering Manager đã diễn ra tốt đẹp với những chia sẻ bổ ích từ hai anh Lê Nguyễn Tường Vũ và Huỳnh Thảo Hạnh Duy.

Nếu bạn không có cơ hội theo dõi trực tuyến vào thứ 7 vừa rồi, bạn có thể thao khảo offline tại đây.

Những bài viết hay

Những điều bạn cần biết về Domain-Driven Design — medium.com

Ngày nay, chúng ta áp dụng Agile software development để giải quyết việc mô hình kinh doanh thay thổi liên tục và nhanh chóng (change request). Tuy nhiên sự thay đổi liên tục này cũng đồng nghĩa codebase cần được thay đổi và trở nên phức tạp. Hiện tượng này được gọi là software entropy.

Vấn đề giao tiếp giữa developers và business experts (người hiểu rõ business - đó có thể là Product Manager hay Product Owner) cũng là một thách thức không nhỏ. Developer thường chú trọng vào vấn đề kĩ thuật nhiều hơn, ở phía đối diện business experts lại chú trọng business. Điều này rất dễ dẫn tới business expert muốn một tính năng A nhưng developers lại làm ra một tính năng B.

Nhìn lại, khía cạnh phức tạp nhất của dự án phần mềm không phải là implementation, đó chính là độ phức tạp của vấn đề mà phần mềm cần giải quyết.

Để giải quyết những điều này, Eric Evans đề xuất một hướng tiếp cận mới, mang tên Domain-Driven Design. Ông đưa ra các khái niệm như:

Bounded Context để gói gọn vấn đề trong một ngữ nghĩa nhất định. Điều này sẽ hạn chế sự phức tạp hoá vấn đề và cũng tránh làm codebase phức tạp theo thời gian
Ubiquitous Language một dạng ngôn ngữ mà khi tham gia thảo luận tất cả thành viên trong team, bao gồm cả business experts, đều hiểu rõ
Entity, Value Object, Aggregate v.v.

Bài viết sau đây, tác giả Pablo Martinez sẽ giải thích rõ hơn về các điểm cốt lõi của Domain-Driven Design.

Making Vue 3 – Increment — increment.com

Trong bài viết, Evan You - tác giả của framework Vue.js - đã chia sẻ những kinh nghiệm của anh ấy và Vue team trong quá trình phát triển Vue 3 - phiên bản sắp được ra mắt trong nửa đầu năm 2020 bao gồm chuyển qua sử dụng TypeScript thay cho Flow type checker, loại bỏ bottleneck của virtual DOM, tối ưu hoá bundle size, xây dựng kiến trúc mới để hỗ trợ tính mở rộng tốt hơn v.v.

Go and CPU Caches — medium.com

Việc hiểu rõ cách hoạt động của phần cứng sẽ giúp chúng ta lập trình tốt hơn, thiết kế các thuật toán cũng như các cấu trúc dữ liệu hiệu quả hơn.

Trong bài viết này, chúng ta sẽ đi vào cách hoạt động của CPU Cache, cũng như một số ví dụ có liên quan trong việc thiết kế thuật toán tối ưu dựa trên cơ chế hoạt động của CPU Cache.

Things we learned about sums — questdb.io

Đối với máy tính, việc biểu thị & tính toán số thập phân khá phức tạp bởi việc phải lưu trữ dưới dạng số nhị phân trong khoảng cho phép. Giống như phân số 1/3 được biểu thị dưới dạng thập phân mà phải giới hạn phần sau dấu phảy, điều này dẫn tới sai số trong việc tính toán. Mặc dù các sai số này thường là nhỏ & chấp nhận được đối với những tính toán cơ bản, nhưng đối với những việc đặc thù như tổng hợp database có tới hàng triệu thậm trí hàng tỉ record dữ liệu, thì sự sai lệch lại ở mức độ khác.

QuestDB phiên bản 4.2.1 cho ra mắt hàm ksum() ứng dụng phương pháp tính tổng Kahan giúp tăng độ chính xác đối với phép tính tổng. Bên cạnh đó nó còn áp dụng phương pháp tính toán song song SIMD giúp cải tiến đáng kể về hiệu năng.

Góc Database

Trong thế giới relational, việc scale các hệ thống database theo chiều ngang là một bài toán khá khó, đặc biệt là vừa phải đảm bảo availability và consistency. Hai phương pháp phổ biến để scale relational database thường được áp dụng là:

- Multi-master replication: thao tác ghi sẽ diễn ra ở một node master, sau đó sẽ được sync qua cho các master khác theo hình thức đồng bộ hoặc bất đồng bộ.

- High-availability cluster: tạo ra 2 hoặc nhiều cluster riêng biệt, mỗi cluster chỉ có 1 master và sẽ được dùng để thay thế khi một trong các cluster chết đi.

Tuy nhiên, cả hai cách trên đều có nhược điểm đi kèm như phải thoả hiệp tính nhất quán dữ liệu, tốn nhiều tài nguyên để fail-over dẫn đến chi phí cao, ... nên để giải quyết bài toán hiệu quả hơn, đội ngũ đằng sau Google Spannner đã đưa ra một số cách tiếp cận khác như:

- Kỹ thuật split trong đó dữ liệu được chia ra lưu trên nhiều read-write replica.

- Quá trình sync dữ liệu giữa các read-write replica dựa trên nguyên tắc QUORUM. Nguyên tắc này khá tương đồng với một vài database khác như Cassandra, ScyllaDB.

- Sử dụng hệ thống lưu trữ file phân tán của Google - Colossus để decouple tầng lưu trữ, từ đó các replica có thể phục hồi dễ dàng khi xảy ra sự cố.

- Và một vài kỹ thuật khác ...

Xem bài viết gốc: https://medium.com/@rakyll/how-does-spanner-avoid-single-point-of-failures-in-writes-4f7765cd894

Tin tức khác về database:

SQL Lite vừa cho ra đời phiên bản 3.32.0: https://sqlite.org/releaselog/3_32_0.html
10 videos ghi lại các bài nói được chia sẻ trong hội nghị RedisConf diễn ra gần đây dành cho các bạn quan tâm đến database này https://www.youtube.com/playlist?list=PL83Wfqi-zYZGPnJqkVn9yeNCMX-V6Pvzm#redistop10

Có thể bạn chưa biết

B-Tree là cấu trúc dữ liệu phổ biến để xây dựng index trong database với đặc điểm:

Một node của B-tree tương ứng với một page của Index File. (Page là đơn vị lưu trữ vật lý nhỏ nhất trong database).
Kích thước mỗi page giống nhau.
Một page trong Index File tương ứng là một node của B-Tree.
Giá trị khoá tìm kiếm và pointer địa chỉ đến data file được lưu trữ trong một node lá của B-Tree trong Index file.
Một page thì chứa nhiều row.
Khi một node lá của B-Tree đầy thì thực hiện tách node để lưu thêm khoá mới.

Có một thông số là Fill factor = X là phần trăm dung lượng tối đa được phép lưu trữ khoá tìm kiếm của một node lá B-Tree. Khi dung lượng đang sử dụng của một node lá B-Tree trên X phần trăm nào đó thì sẽ tiến hành tạo một node mới để lưu khoá tìm kiếm. Dãy gía trị thông thường của Fill factor là [0,100].

Ví dụ nếu Fill factor = 90 nghĩa là khi dung lựơng lưu trữ một node lá của B-Tree đạt mức 90% thì tách node mới. Tìm hiểu cụ thể hơn về fillfactor tại đây.

Code & Tools

Sẽ thế nào nếu bạn biết rằng, chỉ cần một Email ID của bạn, hacker có thể lấy toàn bộ các tài khoản trên các website hay ứng dụng mà bạn đang sử dụng.

Đây chính là một lỗ hổng trong tính năng "Sign in with Apple" cho phép các hacker làm điều đó. Một developer đã nhận được phần thưởng 100.000$ từ Apple sau khi phát hiện lỗ hổng này.

Link chi tiết tại đây: https://bhavukjain.com/blog/2020/05/30/zeroday-signin-with-apple/

Security

Quote

Everything is designed. Few things are designed well.

— Brian Reed

Để giúp cải thiện chất lượng nội dung của newsletter, mong bạn dành ít thời gian phản hồi cũng như đóng góp ý tưởng giúp team thông qua link khảo sát hàng tuần tại đây nhé.