Phát triển hướng hành vi (BDD) hoạt động với Thiết kế điều khiển miền (DDD)

Question

Sự hiểu biết của tôi về BDD là mô tả hệ thống trong các câu chuyện của người dùng và sau đó nhà phát triển lấy những câu chuyện của người dùng đó và biến chúng thành ứng dụng với ý định thêm giá trị kinh doanh thực với mỗi 'chạy nước rút' (giai đoạn phát triển phần mềm). Kết quả (theo như tôi có thể biết) là mô hình miền xuất hiện từ các câu chuyện của người dùng trong suốt quá trình phát triển. Tức là, sau 'lần chạy nước rút' đầu tiên, phần lớn mô hình miền sẽ không được thiết kế.

Hiểu biết của tôi về DDD là phát triển phần mềm tiếp tục với tham chiếu đến mô hình miền đầy đủ, mặc dù mô hình phát triển. Trong DDD, mô hình dự kiến ​​sẽ thay đổi, nhưng dù sao nó vẫn là 'hoàn thành'.

Điều này có vẻ là sự khác biệt cơ bản giữa hai cách tiếp cận. Mọi người xử lý như thế nào?

Answer 1

BDD thực hiện tốt không tạo mô hình "hoàn chỉnh". Có một lý do mà Dan North, người đã đến với BDD, gọi blog của mình là "embracing uncertainty".

Tôi thấy hữu ích trong những ngày này để nghĩ về ba loại thứ mà chúng ta có thể phân tích: cái đã biết, có thể biết và không thể biết được.

Nội dung đã biết rất đơn giản - ví dụ: đăng nhập. Nó được hiểu rõ. Chúng ta không cần nói chuyện qua các kịch bản.

Các nội dung có thể biết thường liên quan đến miền hoặc với nội dung đã được thực hiện trước đó. Đây là một nơi tuyệt vời để làm BDD, bởi vì nó giúp chuyển giao kiến ​​thức - bao gồm cả mô hình miền - từ doanh nghiệp đến các nhà phát triển. Nói chuyện thông qua các kịch bản là một cách tuyệt vời để hiểu câu chuyện tốt hơn. Nó cũng có thể giúp chúng tôi tìm các tình huống mà chúng tôi đã bỏ lỡ. Chris Matts, nhà phân tích đã giúp đưa "Given" trong "Given, When, Then" gọi đây là "phá vỡ mô hình". Ông thực sự cung cấp giải thưởng cho bất cứ ai có thể đưa ra một kịch bản mà không được bao gồm trong mô hình của mình, mà ông sử dụng các kịch bản để xác định và tinh chỉnh.

Ngoài ra còn có những thứ không thể biết. Điều này xảy ra bất cứ khi nào chúng tôi đang làm việc trên một cái gì đó mới, hoặc một cái gì đó chúng tôi đã không bao giờ thực hiện trước đây, hoặc một cái gì đó mà không ai có chuyên môn. Bạn có thể biết bạn đang ở nơi này bởi vì những người kinh doanh sẽ bắt đầu phản ứng với sự ngạc nhiên khi bạn nghĩ ra những kịch bản mà họ chưa từng nghĩ tới. BDD là một cách thực sự tuyệt vời để tìm kiếm những địa điểm này, nhưng tại thời điểm này, bạn có thể muốn ngừng tìm cách khắc phục các tình huống và chỉ cần thử một số thứ và nhận phản hồi. Mô hình miền của bạn cũng như các câu chuyện của người dùng và kịch bản của bạn sẽ dần dần xuất hiện (see the complex domain in the Cynefin model).

Tôi biết rất nhiều nhóm sử dụng BDD như một cách để loại bỏ sự không chắc chắn này. Bạn không thể loại bỏ nó. Bạn chỉ có thể ẩn nó cho đến sau này, khi các phản hồi từ giao hàng trở lại để cắn bạn.

Đối với DDD, khi chúng tôi thực hiện với BDD, chúng tôi có xu hướng tập trung vào các phần của mô hình miền có liên quan đến các tình huống mà chúng tôi đang nghiên cứu, mặc dù chúng tôi có thể có ý tưởng về tên miền lớn hơn mô hình tổng thể. Nếu bạn đang sử dụng Feature Injection cùng với BDD, bạn đã có thể nói chuyện qua hầu hết các khả năng của hệ thống, đặc biệt là các tính năng mới, vì vậy bạn sẽ có ý tưởng về những thứ như thế nào trong miền. Tiến hóa và tất cả các quy tắc khác vẫn được áp dụng. BDD và DDD làm việc thực sự, thực sự tốt với nhau, với các cuộc hội thoại xung quanh các kịch bản giúp đưa ra ngôn ngữ miền. Chúng không khác nhau về cơ bản, nhưng hoàn toàn hỗ trợ và tương thích.

Vui lòng đọc the answer I gave to this similar question, trong đó có video của Dan North và chính tôi nói về chủ đề này.

Answer 2

Tôi sẽ bao gồm các câu chuyện của người dùng, DDD và BDD vì chúng rất phụ thuộc lẫn nhau. Tôi cố gắng để tóm tắt liên kết ở đây: http://christophelecoent.wordpress.com/2013/06/17/how-to-link-user-stories-ddd-and-bdd/

Tôi hy vọng hình ảnh này vừa đơn giản và đủ giàu để giải thích mối liên hệ giữa những "khái niệm"