Methodology, Tản mạn

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

phần mở đầu, mình đã đề cập đến anh em họ hàng trong dòng họ xDD (Driven Design / Development). Và chủ đề chính của loạt bài này là focus vào Domain Driven Development. Trong phần cuối, bằng những kiến thức giới hạn của bản thân, mình sẽ trình bày mối quan hệ của các chú xDD này trong thế giới Software development. Liệu chúng phải loại trừ nhau để kiếm đất sống hoặc có thể cộng sinh để tạo nên một thế giới hòa bình và tốt đẹp hơn.

Thật may là thế giới ngày nay đề cao sự đối thoại hơn là đối đầu.

ndc-2011-specflow-pragmatic-bdd-for-net-6-728

Nguồn hình ảnh: https://www.slideshare.net/jbandi/ndc-2011-specflow-pragmatic-bdd-for-net

Nếu bạn đã từng apply TDD hoặc đơn giản là apply các bộ unit-test và từng xem như là cách để document về hành vi và yêu cầu người dùng mong muốn thì ắt hẳn là gặp không ít khó khăn. Việc viết test trước là cách rất tốt để thiết lập việc suy nghĩ về các vấn đề cần giải quyết trước khi bắt tay vào xử lý chúng. Tuy nhiên, đối với hầu hết các developer, hay nói rộng ra theo một cách khác, khi quá tập trung vào chi tiết – theo hướng emergent design thay vì up-front design – sẽ làm mất tầm nhìn cho các vấn đề lớn hơn, then chốt hơn như tính đúng đắn của requirement. Hay nói một cách khác, sẽ là rất khó để nói rằng TDD sẽ phản ánh được đầy đủ hình hài của user requirement, không thể phản ánh được các use-case mà khách hàng mong muốn.

Dan North đã đẻ ra một hướng tiếp cận khác gọi là Behavior Driven Development với 2 mục đích. Thứ nhất, các bộ test casse BDD được phát triển dựa trên ngôn ngữ tự nhiên sẽ giúp mô tả được cụ thể các use-case mà khách hàng mong muốn, ngôn ngữ tự nhiên này sẽ được “chuẩn hóa” một chút sao cho có cú pháp và có thể dùng các công cụ (như Cucumber) để verify chúng một cách tự động. Thứ hai, BDD sẽ giống như một roadmap giúp cho các developer có thể chèo lái công cuộc TDD của mình một cách có hệ thống, và đúng đắn (TDD Done Right).

Còn DDD, như đã đề cập trong các phần trước, nó chủ yếu focus vào việc develop Business Domain. Trong khi BDD chèo lái hành vi của system thì DDD sẽ mô tả chính xác những gì system cần có. TDD, khi đó sẽ là công cụ để bảo đảm Behavior và Domain sẽ được hiện thực đúng đắn.

Điểm khác biệt rõ ràng giữa chúng chính là chiều hướng của việc thiết kế. DDD theo chiều hướng middle-out. Nghĩa là sẽ bắt đầu với Domain Model, sau đó sẽ làm những phần xung quanh như GUI, DB, integration… Còn BDD, rõ ràng là theo hướng outside-in. Bắt đầu với use-case từ phía người dùng sẽ quyết định những thành phần cần có như Model, DB, UI…

Kết hợp tất cả lại

Thế giới ngày càng ưa chuộng Agile, nếu bạn muốn sử dụng TDD/BDD cùng với việc build một model mạnh với DDD, thì vẫn có cách để làm chuyện đó:

– [DDD] Đầu tiên sẽ tổ chức các buổi domain modelling workshop với domain experts hoặc/và với user để hiểu rõ về domain. Điều này giúp cho team có một cái nhìn tương đối, những hiểu biết ban đầu và các common vocabulary về hệ thống sắp được xây dựng.

– [BDD/ATDD] Với mỗi user story, chúng ta sẽ develop bộ acceptance test scenario. Acceptance Test Driven Development cũng giống như BDD là nó được viết dưới dạng ngôn ngữ tự nhiên để khách hàng có thể hiểu được.

ndc-2011-specflow-pragmatic-bdd-for-net-13-728

Nguồn hình ảnh: https://www.slideshare.net/jbandi/ndc-2011-specflow-pragmatic-bdd-for-net

– [BDD/ATDD] Sau khi đã có bộ acceptance test case, chúng ta sẽ tiến hành việc generate hoặc implement những bộ executable test dựa trên các test case đó. Sau đó sẽ tiến hành develope theo hướng outside-in. Có thể pass các test case bằng cách sử dụng test-double để giả lập những phần chưa hoàn chỉnh trong system nhằm hoàn thành scenario.

– [BDD/TDD] Lúc này kết hợp giữa BDD và TDD để implement những chi tiết còn lại. TDD lúc này là vô cùng quan trọng trong việc hiệu chỉnh (refactor) lại mã nguồn sau này.

– [BDD/TDD/DDD] Sau khi hoàn thành scenario, ta có thể refactor lại code cho đẹp và dễ maintenance. Có thể sử dụng Domain Model patterns (building blocks) để xây dựng phần Model.

– [DDD] Trong quá trình develop, chắc chắn Domain Model sẽ có nhiều thay đổi so với ban đầu, do đó cần phải liên tục update (làm mịn) model vào những thời điểm cần thiết.

Lời kết

Theo phong trào, mình sẽ để lời kết ở đây và không nói gì.

Xem lại các phần khác ở đây:

Và mình sẽ viết riêng 1 bài kết ở đây nữa:

edwardthienhoang

Advertisements

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