Ddd là gì

Hãy nhớ, DDD yêu cầu sự thông suốt trong xây dựng và cài đặt mô hình . Những nhà phân tích, kiến trúc sư hệ thống khi làm việc với các bên liên quan, các chuyên gia nghiệp vụ(Domain Experts), sẽ dựng lên mô hình, trao đổi và nhận được sự đồng thuận với các Domain Experts. Sau đó họ cần truyền đạt và đảm bảo các nhà phát triển, lập trình cũng thông suốt mô hình dựng lên, đến lượt mình các lập trình viên khi cài đặt cũng phải thể hiện được mô hình qua code, và nếu ai đó phát hiện bất kì điểm bất hợp lý gì, sửa đổi gì cần thiết với mô hình trong quá trình làm việc, đều cần thông báo và nhận được sự đồng thuận của nhóm phát triển, hay lớn hơn là được review và đồng thuận từ DE. Và DDD cung cấp các cấu thành nền tảng( building blocks) cho việc xây dựng mô hình mà mọi người cùng hiểu đó. Nó là “từ vựng” để thiết kế mô hình theo DDD.

Bạn đang xem: Ddd là gì

2.2.1 Các cấu thành cơ bản để xây dựng mô hình trong DDD

1. Entity( Thực thể ) dùng để biểu thị các khái niệm mà sự tồn tại của nó liên tục xuyên suốt, dù các thuộc tính có thay đổi.

Ví dụ với một hệ thống quản lý nhân sự, đối tượng nhân viên Employee có các thuộc tính như name, age, address, position; thì theo thời gian thì các thuộc tính này đều có thể thay đổi, được cập nhật, tuy nhiên hệ thống vẫn cần nhận diện 1 nhân viên vẫn là nhân viên đó dù đã cập nhật tuổi, vị trí hay địa chỉ cư trú, hay cả tên cho anh ta trong hoạt động lưu vết cho 1 cá nhân. Vậy Employee cần được xác định là 1 entity.

Để đảm bảo điều này, các lập trình viên sẽ dùng một ID để xác định cho Entity, ID này là duy nhất, xuyên suốt vòng đời của một đối tượng là Entity.Xác định một đối tượng trong mô hình là entity sẽ có các hệ quả quan trọng liên quan đến vòng đời và tương tác của entity đó như: Về cài đặt việc so sánh hai đối tượng entity không được so sánh dựa trên các thuộc tính của nó mà dựa trên ID; Entity có thể thay đổi thuộc tính theo thời gian (mutual) nên không dùng nó để trao đổi thông tin giữa các xử lý; với entity thì cần chú tâm vào cách hàng xử lý nó (behavior) hơn là dữ liệu.

2. Value Object Vâng dịch thô thì nó là loại đối tượng chứa giá trị gì đó ạ, nên Value object chỉ mô tả đặc điểm, thuộc tính của gì đó.

Trong ví dụ trên thì name, age, address, hay position đều là khái niệm thuộc loại Value Object; Nếu giá trị của đối tượng này thay đổi thì nó là đối tượng mới, và nếu giá trị 2 value object như nhau thì có thể dùng thay thế cho nhau. Nghĩa là ở dạng đối tượng này trong dự án chúng ta chỉ quan tâm đến giá trị của nó mà thôi.

Với việc phân định là Value Object hay Entity, DDD đưa ra những gợi ý hữu ích cho thực hành như với Value Object thì seft Validate, còn với Entity thì nên dùng Specification patterns..

3. Service (Dịch vụ) Khi mô hình hóa bài toán thực tế ta cần biểu diễn thực tiễn qua các khái niệm, nhưng Value Object hay Entity thì không đủ, ví dụ để biểu diễn các operations, business policy, process. Ở đây chúng nên được biểu diễn là các service.

Thiết kế một service thì nên là stateless, nghĩa là service sau khi phục vụ xong client thì không nên lưu trữ lịch sử giao dịch phục vụ cho kết quả lần tới, xong thì thôi. Một Service trong DDD là một cấu thành quan trọng của model nên cũng cần được làm rõ trong UL. Một vấn đề lưu ý nữa là phân chia nhiệm vụ cho service ở các tầng khác nhau thì khác nhau, ví như service ở infra có thể lo những dịch vụ hạ tầng về liên lạc, thông báo lỗi, truy xuất cơ sở dữ liệu.. không chứa thông tin về nghiệp vụ. Service ở domain phải mang thông tin về xử lý nghiệp vụ, còn Service ở application có thể kết hợp gọi service ở domain và kết hợp xử lý lỗi, cảnh báo lỗi từ Infra cung cấp, để hoàn thành một business use cases.

Xem thêm: Minecraft Là Gì – Minecraft Có Gì Hay

4. Module Một model lớn có thể chia thành các module, giống như một cuốn sách thì có nhiều chương. Tên module cần nằm trong UL.

Với việc sử dụng Entity, Value Object, Service, Module như những thành phần chính kiến tạo nên model, ta thấy rằng Model driven design được nhắc đến trong DDD khá gần với Object Oriented Design, nhưng không giới hạn.

Trong ứng dụng phần mềm, các đối tượng domain object liên tục được tạo ra, biến đổi, lưu lại, nên có vòng đời (Life cycle). DDD cung cấp các khái niệm:

5. Aggregate hình tượng của aggregate được biểu diễn như một chùm nho, nhiều quả nho chung trên 1 cuống nho nối với thân cây nho. Aggregate đảm bảo tính nhất quán của mọi thay đổi đối với phần tử trong nó. Về cấu tạo Aggregate có một đối tượng root là một entity là đối tượng duy nhất tham chiếu ra bên ngoài. VD trực quan về Aggregate thì Car là aggrate của tire (bánh xe), wheel(vô lăng)..

6. Factory khi việc khởi tạo một Entity hay Value Object phức tạp, bạn hãy ủy nhiệm cho một Factory. Giống như việc tạo ra 1 chiếc xe phụ thuộc vào hàng trăm linh kiện thì bạn cứ ủy quyền cho nhà máy sản xuất rằng làm cho tôi một chiếc xe mui trần, màu xanh, 4 chỗ thay vì nhập về hàng trăm linh kiện và tự lắp ráp.

7. Repository là kho chứa cho bạn lấy ra hay lưu lại các aggregate. Repository là khái niệm thuộc tầng domain không quan tâm đến kỹ thuật, phương tiện lưu trữ(memory hay db..). Cụ thể việc lưu trữ đến đâu do tầng Infra đảm nhiệm, có thể là một ORM để lưu vào Database. Hình minh họa cho Repository là bà thủ thư, bạn đến thư viện nhận và trả sách qua bà thủ thư.

3. Kiến trúc ứng dụng dùng DDD

Các lập trình viên có thể quen với kiến trúc MVC. Nhưng trong sách xanh có nói, đó là những kiến trúc “ông nội” của DDD. Về mặt kiến trúc DDD đề ra việc phân chia làm 4 tầng logic như sau:– UI( Tầng giao diện) : chịu trách nhiệm cho hiển thị thông tin, nhận lệnh từ người dùng– Application( Tầng ứng dụng) : Phối hợp các xử lý. Lưu ý là không chứa logic nghiệp vụ ở đây– Domain (Tầng nghiệp vụ) : Phần này là trái tim của phần mềm, chứa các mô hình biểu diễn nghiệp vụ của hệ thống. Thể hiện logic của nghiệp vụ nhưng uỷ quyền việc cài đặt chi tiết cho Infra. Đây là tầng quan trọng nhất– Infrastructure( Tầng nền) : Cung cấp các gói hỗ trợ, liên lạc, cài đặt chi tiết, sử dụng các thư viện bên ngoài..Phần này đặc biệt quan trọng cho các lập trình viên. Việc thiết lập và giữ vững các quy tắc giao tiếp giữa các lớp, phân chia trách nhiệm hợp lý là điều kiền cần thiết đảm bảo kiến trúc hệ thống.Evan có giới thiệu khá chi tiết về mô hình 4 tầng trong sách của mình kèm ví dụ tham khảo link ở cuối bài. Ngoài ra hiện cộng đồng DDD cũng đề xuất kiến trúc hiện đại có thể dùng với DDD là Hexagonal Architecture hay Port and adapter. Hi vọng có dịp được chia sẽ sâu về kiến trúc.

Trên đây là một số kiến thức cơ sở về DDD để xây dựng mô hình. Phần tiếp theo của DDD cung cấp các hướng dẫn khi phát triển dự án, từng bước hoàn thiện mô hình, xây dựng những ứng dụng lớn. Ở đó DDD đưa ra những gợi ý thiết thực cho quá trình phát triển với các best practices về: – Tái cấu trúc liên tục – Duy trì tính toàn vẹn của mô hình

Xin được cùng thảo luận với các bạn trong bài viết tiếp theo.

4. Vài kinh nghiệm với DDD

4.1. Khó khăn khi học DDD

DDD là một hướng tiếp cận giải quyết cho những phần mềm lớn và phức tạp, vì thế nó áp dụng nhiều design patterns và các best practices. Việc làm chủ những khái niệm này là không dễ và đòi hỏi nhiều kinh nghiệm. Ngoài ra cả team đều phải hiểu và tuân theo các rule của DDD.DDD đòi hỏi cao trong sự cộng tác cao của nhóm phát triển với các chuyên gia về nghiệp vụ. Nếu không phải là một chính sách, quyết tâm của công ty thì cũng gặp nhiều khó khăn để áp dụng.

Xem thêm: Dateline Là Gì – Deadline Là Gì

4.2. DDD và SCRUM

Một điều tôi thấy tuyệt vời là sự tương thích hoàn toàn của DDD với các phương pháp, công cụ phát triển sản phẩm hiện đại. Tính agility của DDD. DDD và SCRUM nhấn mạnh đến sự tương tác, phản hồi, cải tiến liên tục. Khác với Warterfall, khi giả định của chúng ta từng bước hoàn thành từ trên xuống dưới. Nghĩa là yêu cầu đã đc phân tích đầy đủ và kĩ lưỡng rồi thiết kế hoàn chỉnh rồi lập trình theo thiết kế có sẳn, rồi kiểm thử để đảm bảo cài đặt như đặc tả.Ở SCRUM, Ngay trong một Sprint ngắn, hay thậm chí ở Daily meeting khi cài đặt, nhà phát triển có thể nhanh chóng chia sẻ về một cập nhật cho mô hình, nhận sự phản hồi của nhóm , thông báo với PO.. DDD cũng hướng nhóm SCRUM đến mô hình business ngay từ đầu để mường tượng về sự tiến hoá trong tương lai, khi yêu cầu phát triển là chưa xác định. Việc của nhóm phát triển là liên tục cài đặt và cập nhật mô hình để đạt được sự thông suốt, đúng đắn, qua đó việc phát triển phần mềm không phải là công việc khô khan mà giúp thu lượm được nhiều những kiến thức thực tế kinh doanh.Ngoài ra, DDD cũng nhắc đến CI như là công cụ cần thiết cho automation test, auto deployment, hỗ trợ tích cực cho sự tiến hoá của sản phẩm phần mềm.

5. Tài liệu tham khảoDomain Driven Design: tackling complexity in the heart of softwareVí dụ đi kèm với cuốn sách xanh nổi tiếng, các nhà phát triển rất cần nghiên cứu sâu http://dddsample.sourceforge.net/architecture.html

Chuyên mục: Hỏi Đáp