Domain Driven Design Là Gì

     

*
Chào các bạn! Sau hơn 1 năm thao tác làm việc với DDD, tôi thấy DDD thật là một tư duy mới về cách xây dựng phần mềm. Nhấn thấy cách thức thiết kế này còn khá mới mẻ ở Việt nam, đề nghị tôi xin share tổng hợp cơ bản về DDD dành fan quan tâm. Bạn có thể là developer, SQA, managers, PO.. Miễn là bạn tương quan đến phát triển xây dựng hệ thống phức tạp thì DDD đều có thể mang lại bạn những gợi ý hữu ích. Do kiến thức còn hạn hẹp tương tự như nhiều góc nhìn chủ quan có thể thiếu sót, mong muốn nhận được góp ý của các bạn để bài viết được bổ xung hoàn thiện hơn.

Bạn đang xem: Domain driven design là gì

1. DDD là gì

1.1 Khái niệm

Domain-driven thiết kế (DDD) là một cách tiếp cận cho cải tiến và phát triển các phần mềm phức tạp; sự phức hợp ở đây là do nhiệm vụ của lĩnh vực kinh doanh (domain business). Bí quyết tiếp cận của DDD là kết nối nghiêm ngặt việc cài đặt phần mềm với sự tiến hoá của quy mô kinh doanh: – dự án đặt sự chú trọng những cho phần nghiệp vụ chính (core domain) và các logic nhiệm vụ liên quan. – quy mô hoá của nhiệm vụ là trọng tâm, căn cơ cho mọi setup phần mềm. – tăng tốc cộng tác giữa đội kỹ thuật( developers) và các chuyên gia nghiệp vụ (domain expert) để xây dựng một tế bào hình xuất sắc giúp xác minh và giải quyết công dụng bài toán. Wiki

DDD được người sáng tác Eric Evan chỉ dẫn sau kinh nghiệm khoảng 20 năm tham gia phát triển phần mềm, xây dựng những ứng dụng khủng cho giới tài chính, ngân hàng, bảo hiểm, luân chuyển quốc tế.. Dựa trên kinh nghiệm tay nghề thực tiễn, những best practices tích luỹ được, ông khuyến cáo một phương pháp tiếp cận mới để xây dựng những phần mềm gồm nghiệp vụ tinh vi mà nhóm phát triển sẽ chạm chán rất các khó khăn để làm chủ, cai quản rủi ro, trở nên tân tiến và trùng tu lâu dài. Phương thức của ông được tổng hợp trong cuốn sách xanh danh tiếng ” domain name Driven thiết kế – tackling complexity in the heart of software” tự 2003. Và cách thức đã hối hả nhận được sự tâng bốc của cộng đồng, ngày càng được cách tân và phát triển và áp dụng.

1.2 Use case

Tại Septeni-Technology: từ nhu yếu phát triển những sản phẩm toàn cầu, unique cao, dễ bảo trì, mở rộng yên cầu thống nhất một phương pháp luận cải cách và phát triển dự án vào công ty, DDD đã làm được lựa chọn do CTO tự Nhật bản và yêu cầu trở thành trong số những nền tảng trở nên tân tiến của Septeni Technology. Tất cả nhân viên của Septeni giải pháp công nghệ đều cần phải có kiến thức về DDD cho dù ở những cấp độ khác nhau; DDD cũng hoàn toàn tương yêu thích với SCRUM cùng yêu cầu cả đội dự án gồm developer, SQA, PO đều yêu cầu hiểu. Là một cách tiếp cận hiện nay đại, với việc tổng hợp kỹ năng từ một architect nhiều năm khiếp nghiệm, DDD hỗ trợ nhiều best practices, design patterns hữu ích. Với từng cá nhân thực hành DDD giúp cho bạn nâng cấp kỹ năng về phân tích thiết kế, tổ chức triển khai mã nguồn, hiểu sâu sắc và nghiệp vụ, duy trì kết nối giỏi với team. Vì thế kể cả bạn không tồn tại điều kiện vận dụng nó trong công việc hiện trên tôi vẫn lời khuyên với bạn nên đọc nếu bạn đang có tác dụng trong lĩnh vực phần mềm.

2. Gốc rễ cơ bản của DDD

2.1 ngôn ngữ chung

Yêu cầu thứ nhất của bí quyết tiếp cận DDD là ngôn ngữ Chung (UL). DDD nhấn mạnh vấn đề sự cùng tác, không bó bé nhỏ giữa những lập trình viên cùng với nhau, cho nên những người tương quan phải có tác dụng trao đổi để thuộc hiểu một sự việc nghiệp vụ. Thực tế chỉ ra rằng những từ vựng “chuyên nghành” rất giản đơn bị hiểu sai với người ngoài nghành, thậm chí còn cùng một thuật ngữ không giống nhau theo những vai trò khác nhau, định nghĩa cũng hoàn toàn có thể khác nhau. ** lấy một ví dụ ** thực tế trong dự án công trình gần đây, nhóm tôi bao gồm nhận được yêu cầu về làm chủ các dự án cho khách hàng hàng. Cùng khi bàn thảo team tưởng tượng rằng dự án sẽ có được các trực thuộc tính bắt đầu, kết thúc, giá chỉ thành, nhân viên, rồi để chấm dứt sẽ có không ít nhiệm vụ gán cho những thành viên trong đội. Team tưởng tượng tới những trello, jira, dotproject. Nhưng trong tương lai khi nhận được sample từ quý khách mới phân biệt Project chỉ tương đương với một bản ghi exel tương xứng với một code từ hoá 1-1 gán mang đến một fan phụ trách. Vậy làm nuốm nào để có ngôn ngữ bình thường để ai tham gia dự án công trình cũng thống độc nhất vô nhị một phương pháp hiểu, gồm thể share với nhân viên kinh doanh hay nhân viên kỹ thuật. Evan gợi nhắc rằng nó là tài liệu nhằm mọi bạn cùng hiểu. Ví dụ khi so sánh về một khối hệ thống quảng cáo , qua trao đổi, nhà phân tích thấy được một trong những yêu mong và chỉ dẫn một giản đồ:

*
thêm vào đó đó là 1 từ điển thuật ngữ dự án, giải thích cụ thể khái niệm các phần tử trong giản đồ. Với tài liệu đơn giản này, ta có thể dễ dàng chia sẻ, confirm hệ thống với các chuyên viên nghiệp vụ như thể nhân viên marketing quảng cáo, nhà quản lý, hay bàn luận giữa team dự án, để thuộc nhau khai thác ra những vấn đề cốt lõi, thâm thúy hơn . Điều này còn có vẻ cũng không mới trong phân tích dự án, nhưng với DDD đó là yêu cầu xuyên suốt vòng đời sản phẩm, DDD yêu thương cầu quy mô phân tích(analysis) cùng mô hình thiết lập (coding) là một, phản ánh lẫn nhau.

2.2 thiết kế hướng mô hình (model driven design)

*
Hãy nhớ, DDD yêu ước sự nối liền trong xây dừng và cài đặt mô hình . Những nhà phân tích, phong cách xây dựng sư khối hệ thống khi thao tác với các bên liên quan, các chuyên gia nghiệp vụ(Domain Experts), đang dựng lên tế bào hình, thảo luận và nhận thấy sự đồng thuận với các Domain Experts. Sau đó họ cần truyền đạt và đảm bảo các công ty phát triển, lập trình sẵn cũng thông suốt quy mô dựng lên, đến lượt mình những lập trình viên khi thiết lập cũng bắt buộc thể hiện tại đượ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 thay đổi gì cần thiết với quy mô trong quy trình làm việc, gần như cần thông báo và nhận thấy sự đồng thuận của group phát triển, hay to hơn là được reviews và đồng thuận trường đoản cú DE. Cùng DDD cung ứng 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 bạn cùng đọc đó. Nó là “từ vựng” để kiến tạo mô hình theo DDD.

2.2.1 những cấu thành cơ bản nhằm xây dựng mô hình trong DDD

1. Entity( Thực thể ) sử dụng để bộc lộ các khái niệm cơ mà sự vĩnh cửu của nó liên tục xuyên suốt, dù các thuộc tính bao gồm thay đổi.

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

Để bảo đảm an toàn điều này, các lập trình viên sẽ cần sử dụng một ID để xác định mang đến Entity, ID này là duy nhất, xuyên thấu vòng đời của một đối tượng là Entity.Xác định một đối tượng trong quy mô là entity sẽ có được các hệ quả đặc trưng liên quan mang đến vòng đời và can hệ của entity kia như: Về thiết đặt việc so sánh hai đối tượng entity không được đối chiếu dựa trên những thuộc tính của nó mà dựa trên ID; Entity bao gồm thể biến đổi thuộc tính theo thời gian (mutual) đề xuất không sử dụng nó để trao đổi thông tin giữa những xử lý; với entity thì cần chăm bẵm vào cách hàng xử trí nó (behavior) rộng là dữ liệu.

2. Value Object Vâng dịch thô thì nó là loại đối tượng chứa giá trị gì đó ạ, nên Value object chỉ tế bào tả đặc điểm, thuộc tính của gì đó.

Trong ví dụ bên trên thì name, age, address, tuyệt position đều là khái niệm thuộc loại Value Object; Nếu giá trị của đối tượng này nuốm đổi thì nó là đối tượng mới, và nếu giá trị 2 value object hệt nhau thì có thể dùng cố gắng thế mang đến nhau. Nghĩa là ở dạng đối tượng này trong dự án chúng ta chỉ vồ cập đến giá trị của nó mà thôi.

Với việc phân định là Value Object hay Entity, DDD đưa ra những gợi ý hữu ích mang đến thực hành như với Value Object thì seft Validate, còn với Entity thì phải dùng Specification patterns..

Xem thêm: 30+ Cách Làm Đồ Trang Trí Phòng Bằng Giấy Ấn Tượng Cho Không Gian Nhà Bạn

3. Service (Dịch vụ) lúc mô hình hóa bài toán thực tế ta cần biểu diễn thực tiễn qua các khái niệm, mà lại Value Object tốt Entity thì không đủ, ví dụ để biểu diễn các operations, business policy, process. Ở phía trên chúng phải được biểu diễn là các service.

Thiết kế một service thì nên là stateless, nghĩa là service sau thời điểm phục vụ kết thúc client thì tránh việc lưu trữ lịch sử giao dịch phục vụ cho kết quả lần tới, kết thúc thì thôi. Một Service vào DDD là một cấu thành quan lại trọng của model nên cũng cần được làm rõ trong UL. Một vấn đề giữ ý nữa là phân loại nhiệm vụ mang đến service ở các tầng khác nhau thì khác nhau, ví như service ở infra có thể lo những dịch vụ hạ tầng về liên lạc, thông báo lỗi, tầm nã xuất cơ sở dữ liệu.. Không chứa thông tin về nghiệp vụ. Service ở domain phải mang tin tức về xử lý nghiệp vụ, còn Service ở application có thể kết hợp gọi service ở tên miền và kết hợp xử lý lỗi, cảnh báo lỗi từ Infra cung cấp, để hoàn thành một business use cases.

4. Module Một model lớn có thể chia thành các module, giống như một cuốn sách thì có nhiều chương. Tên module cần nằm vào UL.

Với việc sử dụng Entity, Value Object, Service, Module như những thành phần chính kiến tạo nên model, ta thấy rằng mã sản phẩm driven design được nhắc đến trong DDD khá gần với Object Oriented Design, tuy thế không giới hạn.

Trong ứng dụng phần mềm, các đối tượng tên miền object liên tục được tạo ra, biến đổi, giữ lại, phải có vòng đời (Life cycle). DDD cung cấp các khái niệm:

5. Aggregate hình tượng của aggregate được biểu diễn như một chùm nho, nhiều quả nho thông thường trên 1 cuống nho nối với thân cây nho. Aggregate đảm bảo tính nhất quán của mọi cụ đổi đối với phần tử trong nó. Về cấu tạo Aggregate có một đối tượng root là một entity là đối tượng duy nhất tham chiếu ra mặt ngoài. VD trực quan liêu về Aggregate thì car là aggrate của tire (bánh xe), wheel(vô lăng)..

6. Factory khi việc khởi tạo một Entity xuất xắc Value Object phức tạp, bạn hãy ủy nhiệm mang lại một Factory. Giống như việc tạo ra 1 chiếc xe pháo phụ thuộc vào hàng trăm linh kiện thì bạn cứ ủy quyền đến nhà máy sản xuất rằng làm mang lại tôi một chiếc xe pháo mui trần, màu xanh, 4 chỗ cụ vì nhập về hàng trăm linh kiện và tự lắp ráp.

7. Repository là kho chứa mang đến bạn lấy ra tốt lưu lại các aggregate. Repository là khái niệm thuộc tầng tên miền không thân mật đến kỹ thuật, phương tiện giữ trữ(memory hay db..). Cụ thể việc lưu giữ trữ đến đâu bởi tầng Infra đảm nhiệm, có thể là một ORM để giữ vào Database. Hình minh họa đến Repository là bà thủ thư, bạn đến thư viện nhận và trả sách qua bà thủ thư.

3. Bản vẽ xây dựng ứng dụng dùng DDD

Các lập trình sẵn viên rất có thể quen với phong cách thiết kế MVC. Nhưng lại trong sách xanh có nói, đó là những phong cách xây dựng “ông nội” của DDD. Về mặt kiến trúc DDD đặt ra việc phân chia thành 4 tầng lô ghích như sau: – UI( Tầng giao diện) : phụ trách cho hiển thị thông tin, dấn lệnh từ người dùng – Application( Tầng ứng dụng) : kết hợp các xử lý. Chú ý là ko chứa xúc tích nghiệp vụ tại đây – Domain (Tầng nghiệp vụ) : Phần này là trái tim của phần mềm, chứa các quy mô biểu diễn nghiệp vụ của hệ thống. Thể hiện lô ghích của nghiệp vụ nhưng uỷ quyền việc thiết lập chi tiết mang đến Infra. Đây là tầng quan trọng nhất – Infrastructure( Tầng nền) : cung ứng các gói hỗ trợ, liên lạc, setup chi tiết, sử dụng các thư viện mặt ngoài.. Phần này đặc trưng quan trọng cho các lập trình viên. Việc tùy chỉnh cấu hình và giữ vững những quy tắc giao tiếp giữa các lớp, phân loại trách nhiệm phù hợp là điều kiền phải thiết đảm bảo bản vẽ xây dựng hệ thống. Evan có ra mắt khá cụ thể về quy mô 4 tầng vào sách của chính bản thân mình kèm ví dụ tham khảo links ở cuối bài. Dường như hiện xã hội DDD cũng đề xuất kiến trúc văn minh có thể dùng với DDD là Hexagonal Architecture giỏi Port và adapter. Hy vọng có thời gian được chia sẽ sâu về loài kiến trúc.

Trên phía trên là một số kiến thức cơ sở về DDD để xây dựng tế bào hình. Phần tiếp theo của DDD cung cấp các hướng dẫn lúc phát triển dự án, từng bước hoàn thiện mô hình, xây dựng những ứng dụng lớn. Ở đó DDD giới thiệu những lưu ý thiết thực mang đến quá trình cải cách và phát triển với những best practices về: – Tái cấu trúc liên tục – bảo trì tính toàn vẹn của mô hình

Xin được cùng thảo luận với các bạn trong bài viết tiếp theo.

4. Vài tởm nghiệm với DDD

4.1. Khó khăn khi học DDD

DDD là một hướng tiếp cận giải quyết mang lại những phần mềm lớn và phức tạp, vì thế nó áp dụng nhiều thiết kế patterns và các best practices. Việc làm chủ những khái niệm này là ko dễ và đòi hỏi nhiều gớm nghiệm. Ngoài ra cả team đều phải hiểu và tuân thủ theo đúng các rule của DDD.DDD đòi hỏi cao vào sự cộng tác cao của nhóm phát triển với các chuyên viên về nghiệp vụ. Nếu ko phải là một chính sách, quyết trọng điểm của doanh nghiệp thì cũng gặp nhiều khó khăn để áp dụng.

Xem thêm: Thế Giới Không Tình Yêu Là Gì Mà Thế Giới Phải Khóc, Tình Yêu Là Gì Mà Thế Giới Phải Khóc

4.2. DDD và SCRUM

Một điều tôi thấy hoàn hảo nhất là sự tương thích trọn vẹn của DDD với những phương pháp, công cụ phát triển sản phẩm hiện tại đại. Tính agility của DDD. DDD và SCRUM thừa nhận mạnh đến việc tương tác, bội nghịch hồi, đổi mới liên tục. Không giống với Warterfall, khi mang định của chúng ta từng bước hoàn thành từ bên trên xuống dưới. Nghĩa là yêu ước đã đc phân tích rất đầy đủ và kĩ lưỡng rồi thiết kế hoàn chỉnh rồi lập trình theo xây cất có sẳn, rồi kiểm demo để đảm bảo an toàn cài đặt như sệt tả. Ở SCRUM, ngay lập tức trong một Sprint ngắn, hay thậm chí còn ở Daily meeting khi thiết lập đặt, đơn vị phát triển hoàn toàn có thể nhanh chóng chia sẻ về một cập nhật cho tế bào hình, nhấn sự phản bội hồi của nhóm , thông tin với PO.. DDD cũng hướng nhóm SCRUM đến quy mô business ngay từ trên đầu để mường tượng về sự tiến hoá vào tương lai, khi yêu cầu trở nên tân tiến là chưa xác định. Việc của tập thể nhóm phát triển là liên tục thiết lập và update mô hình để dành được sự thông suốt, đúng đắn, qua đó việc phát triển phần mềm không phải là công việc ráo mát mà giúp thu lượm được nhiều những kiến thức thực tế kinh doanh. Ngoài ra, DDD cũng nhắc đến CI như là công cụ cần thiết cho automation test, auto deployment, cung ứng tích cực cho sự tiến hoá của thành phầm phần mềm.

5. Tài liệu tham khảoDomain Driven Design: tackling complexity in the heart of softwareVí dụ đi kèm với cuốn sách xanh nổi tiếng, các nhà phát triển rất cần nghiên cứu sâu http://dddsample.sourceforge.net/architecture.html