Methodology, Tản mạn

Domain Drive Development (DDD) – First thought – Part 2

phần 1, chúng ta đã hiểu được vai trò của nắm bắt kiến thức về Domain trong việc phát triển phần mềm. Ở phần này chúng ta sẽ xem xét 1 approach để đạt được điều đó, đó chính là Domain Driven Design.

Domain Driven Design

Domain Driven Design (DDD) khác với Domain Driven Development (cũng là DDD) như thế nào. Nói một cách đơn giản Development là 1 quá trình bao hàm toàn bộ quá trình phát triển của 1 sản phẩm phần mềm, bao gồm các khâu Analysis, Design, Coding, Testing, Delivery,… Nói như vậy chắc cũng đủ để hiểu Domain Driven Design nằm ở đâu trong đây. Đó là 1 khâu của quá trình Development, chú trọng chủ yếu vào việc thiết kế (Design) mô hình (model) và kiến trúc (architecture) cho dự án.

Theo định nghĩa từ DDD Community: “Domain-driven design is not a technology or a methodology. DDD provides a structure of practices and terminology for making design decisions that focus and accelerate software projects dealing with complicated domains.
Nghĩa là: “Thiết kế hướng nghiệp vụ không phải là 1 công nghệ hay phương pháp luận gì, mà nó chỉ cung cấp 1 loạt các cách thực hành và các thuật ngữ được sử dụng trong việc thiết kế để giải quyết các hệ thống software có độ phức tạp cao về nghiệp vụ.

Tuy mỗi phần trong quá trình phát triển sản phẩm là riêng biệt với nhau nhưng chúng có quan hệ mật thiết, và có 1 số khâu sẽ xuyên suốt từ đầu đến cuối quy trình. Ở đây chúng ta sẽ xem xét Domain Driven Design chủ yếu ở khâu phân tích và thiết kế, và xem xét làm thế nào để tích hợp tất cả vào một quy trình hoàn chỉnh.

Domain Driven Design được giới thiệu bởi Eric Evans cách đây hơn 10 năm (gần 20 năm cũng nên). Là 1 approach mới trong việc thiết kế và phát triển các hệ thống software phức tạp về mặt nghiệp vụ, trong đó lấy domain làm trọng tâm, mọi chủ thể từ khách hàng (Domain Expert), BA (Business Analyst), Developer, và các giai đoạn thiết kế, phát triển đều dựa trên domain, coi domain như là trái tim của dự án. Cuốn sách rất nổi tiếng của ông có tên “Domain-Driven Design: Tackling Complexity in the Heart of Software“.

51sZW87slRL._SX375_BO1,204,203,200_

Ở đây, Evans gọi Domain là the Heart of Software. Nghĩa là để có 1 cơ thể cường tráng, không bệnh tật thì cần 1 trái tim khỏe mạnh. (Quảng cáo dầu ăn thì phải)

Start with Domain

Để xây dựng 1 hệ thống phần mềm, không phải chỉ có việc “sit down and type code”. Để tạo ra 1 sản phẩm chất lượng làm hài lòng thượng đế, chúng ta cần biết các thượng đế muốn gì. Bạn không thể viết ra 1 banking software mà không hề có tí kiến thức nào về domain này (ngoại trừ việc rút tiền ở cây ATM). Vậy ai trong đội dự án có thể hiểu được domain này? Kiến trúc sư (software architecture)? Ổng chỉ biết ra ngân hàng tạo tài khoản tiết kiệm hoặc chuyển tiền lương vào tài khoản của “sếp lớn” ở nhà thôi. Software analyst? Ông này có khả năng phân tích các vấn đề được giao, nhiệm vụ chính của ổng. Chúng ta (developer)? Có khả năng lắm chứ :)). Nói toẹt ra thì không ai hiểu khách hàng muốn gì bằng chính họ, ở đây là các bankers, họ hiểu họ muốn gì, các quy tắc, nghiệp vụ, và ta gọi họ là các Domain Expert. Cần hiểu cái mình sẽ làm trước khi làm, đó chính là lý do vì sao nên bắt đầu nói chuyện với các Expert về Domain của họ.

Modelling the Domain

OK! Đi nói chuyện với các chuyên gia. Ai đi đây? Như đã đề cập ở phần trước, BA (Business Analyst) là những người thích hợp nhất. Họ có tài ăn nói, khả năng phân tích vấn đề và có hiểu biết 1 chút về các vấn đề kỹ thuật, và quan trọng nhất chính là khả năng modelling, truyền tải các thông điệp từ dạng ngôn ngữ tự nhiên thành các dạng ngôn ngữ, lược đồ sao mà tất cả các bên cùng có thể hiểu đúng về vấn đề, quan trọng nhất là giữa các Domain Expert và BA, họ phải hiểu được nhau.

The Ubiquitous Language

Class Diagram sử dụng UML cũng là 1 ý tưởng, nó dùng để mô hình hóa các thực thể bên ngoài vào trong concept của việc development, nhưng nó lại quá đi sâu vào các chi tiết như kế thừa, interface, method, attribute.. Không khả thi lắm. Use-case diagram thì chỉ tập trung vào các thao tác nghiệp vụ, không cho ta cái nhìn rõ hơn về các loại hình đối tượng có trong nghiệp vụ.

Nguyên lý cốt lõi của Domain Driven Design chính là sử dụng 1 ngôn ngữ dựa trên model. Model chính là xương sống (backbone) của system, nó cần phải thống nhất trong tất cả các cuộc nói chuyện cũng như trong quá trình viết mã. Vì vậy, Evans đã đưa ra 1 khái niệm đó là Ubiquitous Language (ngôn ngữ chung) dùng để làm công cụ giao tiếp giữa bên Domain Expert và bộ phận phát triển.

Việc tham gia và quy trình chuyển đổi ngôn ngữ tự nhiên thành dạng ngôn ngữ chung thường chủ yếu là sự có mặt của Domain Expert và BA, tuy nhiên việc 1 số thành viên trong đội Developer tham gia sẽ giúp cho họ có cái nhìn trực diện hơn về các vấn đề thực tế về nghiệp vụ, cũng như việc hài hòa giữa nghiệp vụ và kỹ thuật.

Bài viết chỉ ở dạng concept nên sẽ không đi chi tiết vào việc thiết kế Ubiquitous Language như thế nào.

Tạm dừng phần 2 ở đây, ở phần 3 chúng ta sẽ tìm hiểu về Model-driven Design. Phần này sẽ tập trung sâu hơn thiết kế về mặt kỹ thuật lấy Model làm trung tâm.

edwardthienhoang.

Advertisements

3 thoughts on “Domain Drive Development (DDD) – First thought – Part 2”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s