Domain driven design là gì

     

*
Chào các bạn! Sau rộng 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. Dìm thấy cách thức thiết kế này còn khá mớ lạ và độc đáo ở Việt nam, nên tôi xin share tổng vừa lòng cơ phiên bản về DDD dành bạn quan tâm. Bạn có thể là developer, SQA, managers, PO.. Miễn là bạn liên quan đến phát triển xây dựng hệ thống phức tạp thì DDD đều có thể cho bạn những gợi ý hữu ích. Do kỹ năng và kiến thức còn hạn hẹp cũng như nhiều ánh mắt chủ quan hoàn toàn có thể thiếu sót, ý muốn nhận được góp ý của chúng ta để 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 design (DDD) là một trong cách tiếp cận cho cải tiến và phát triển các ứng dụng phức tạp; sự phức hợp ở đấy là do nghiệp vụ của lĩnh vực sale (domain business). Giải pháp tiếp cận của DDD là kết nối chặt chẽ việc cài đặt phần mềm với việc tiến hoá của quy mô kinh doanh: – dự án đặt sự chú trọng nhiều cho phần nghiệp vụ chính (core domain) và các logic nhiệm vụ liên quan. – mô hình hoá của nhiệm vụ là trọng tâm, căn nguyên cho mọi setup phần mềm. – tăng tốc cộng tác giữa team kỹ thuật( developers) với các chuyên gia nghiệp vụ (domain expert) để xây cất một tế bào hình xuất sắc giúp khẳng định và giải quyết hiệu quả bài toán. Wiki

DDD được người sáng tác Eric Evan giới thiệu sau kinh nghiệm tay nghề khoảng 20 năm tham gia cải tiến và phát triển phần mềm, xây dựng đầy đủ ứng dụng béo cho giới tài chính, ngân hàng, bảo hiểm, giao vận quốc tế.. Dựa trên tay nghề thực tiễn, số đông best practices tích luỹ được, ông khuyến cáo một cách thức tiếp cận mới để xây dựng những phần mềm tất cả nghiệp vụ tinh vi mà nhóm trở nên tân tiến sẽ chạm mặt rất các khó khăn để làm chủ, quản lý rủi ro, trở nên tân tiến và duy tu lâu dài. Phương thức của ông được tổng vừa lòng trong cuốn sách xanh khét tiếng ” tên miền Driven thiết kế – tackling complexity in the heart of software” tự 2003. Và cách thức đã nhanh lẹ nhận được sự tán dương của cộng đồng, ngày dần được cải cách 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, quality cao, dễ bảo trì, mở rộng yên cầu thống độc nhất một cách thức luận cách tân và phát triển dự án trong công ty, DDD đã làm được lựa chọn vì 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 có kiến thức về DDD mặc dù ở những cấp độ không giống nhau; DDD cũng trọn vẹn tương ưng ý với SCRUM và yêu mong cả đội dự án công trình gồm developer, SQA, PO đều đề xuất hiểu. Là một trong cách tiếp cận hiện đại, với việc tổng hợp kỹ năng và kiến thức từ một architect những năm ghê nghiệm, DDD hỗ trợ nhiều best practices, kiến thiết patterns hữu ích. Cùng với từng cá thể thực hành DDD khiến cho bạn nâng cấp kỹ năng về đối chiếu thiết kế, tổ chức mã nguồn, hiểu thâm thúy và nghiệp vụ, giữ lại kết nối xuất sắc 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 quá trình hiện tại tôi vẫn đề xuất với bạn nên đọc nếu như khách hàng đang có tác dụng trong nghành nghề dịch vụ phần mềm.

2. Căn nguyên cơ bản của DDD

2.1 ngôn ngữ chung

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

*
thêm vào đó đó là 1 trong những từ điển thuật ngữ dự án, giải thích cụ thể khái niệm các phần tử vào giản đồ. Cùng với tài liệu đơn giản dễ dàng này, ta hoàn toàn có thể dễ dàng phân tách 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, bên quản lý, hay đàm đạo giữa team dự án, để cùng nhau khai phá ra các vấn đề cốt lõi, sâu sắc hơn . Điều này còn có vẻ cũng không mới trong so với dự án, tuy nhiên với DDD đây 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 cài đặt (coding) là một, phản ánh lẫn nhau.

2.2 xây dựng hướng mô hình (model driven design)

*
Hãy nhớ, DDD yêu ước sự nối tiếp trong xây cất và cài đặt mô hình . đầy đủ nhà phân tích, kiến trúc sư khối hệ thống khi thao tác làm việc với các bên liên quan, các chuyên gia nghiệp vụ(Domain Experts), vẫn dựng lên mô hình, điều đình và nhận ra sự đồng thuận với những Domain Experts. Tiếp đến họ phải truyền đạt và bảo vệ các bên phát triển, lập trình sẵn cũng thông suốt mô hình dựng lên, cho lượt mình các lập trình viên khi thiết đặt cũng bắt buộc thể hiện tại được quy mô qua code, và nếu ai kia phát hiện bất kể điểm bất phù hợp gì, sửa đổi gì cần thiết với quy mô trong quy trình làm việc, số đông cần thông báo và cảm nhận sự đồng thuận của tập thể nhóm phát triển, hay lớn hơn là được reviews và đồng thuận tự DE. Với DDD cung cấp các cấu thành nền tảng( building blocks) cho vấn đề xây dựng mô hình mà mọi bạn cùng đọc đó. Nó là “từ vựng” để thiết kế 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ể ) cần sử dụng để bộc lộ các khái niệm mà lại sự vĩnh cửu của nó tiếp tục xuyên suốt, dù những thuộc tính có thay đổi.

Ví dụ với 1 hệ thống thống trị nhân sự, đối tượng người tiêu dùng nhân viên Employee có các 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 có thể thay đổi, được cập nhật, tuy nhiên khối hệ thống vẫn bắt buộc nhận diện 1 nhân viên vẫn luôn là nhân viên kia dù đã cập nhật tuổi, địa điểm hay địa chỉ cửa hàng cư trú, tốt cả tên cho anh ta trong chuyển động lưu vết cho 1 cá nhân. Vậy Employee buộc phải được xác minh là 1 entity.

Để đảm bảo điều này, các lập trình viên sẽ cần sử dụng một ID nhằm xác định cho 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 người tiêu dùng trong mô hình là entity sẽ có các hệ quả đặc trưng liên quan mang lại vòng đời và hệ trọng của entity đó như: Về setup việc so sánh hai đối tượng entity ko được so sánh dựa trên những thuộc tính của nó mà dựa vào ID; Entity bao gồm thể thay đổi thuộc tính theo thời gian (mutual) đề nghị không sử dụng nó nhằm trao đổi thông tin giữa những xử lý; cùng với entity thì cần chú tâm vào cách hàng cách xử trí nó (behavior) hơn 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ì đó ạ, đề xuất 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, giỏi position đều là khái niệm thuộc loại Value Object; Nếu giá trị của đối tượng này thay đổi thì nó là đối tượng mới, và nếu giá trị 2 value object giống hệt thì có thể dùng thế thế mang lại nhau. Nghĩa là ở dạng đối tượng này vào dự án chúng ta chỉ thân thiện đến giá trị của nó mà thôi.

Với việc phân định là Value Object giỏi Entity, DDD giới thiệu những gợi ý hữu ích mang lại thực hành như với Value Object thì seft Validate, còn với Entity thì đề xuất dùng Specification patterns..

Xem thêm: Tapeworm Là Gì ? Những Điều Bạn Cần Biết Về Các Bệnh Sán Dây

3. Service (Dịch vụ) khi 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, dẫu vậy Value Object hay Entity thì không đủ, ví dụ để biểu diễn các operations, business policy, process. Ở đây chúng bắt buộc được biểu diễn là các service.

Thiết kế một service thì đề xuất là stateless, nghĩa là service sau khoản thời gian phục vụ xong client thì không nên lưu trữ lịch sử giao dịch phục vụ mang lại kết quả lần tới, dứt thì thôi. Một Service trong 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õ vào UL. Một vấn đề lưu giữ ý nữa là phân chia nhiệm vụ đế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, truy nã xuất cơ sở dữ liệu.. Ko chứa tin tức về nghiệp vụ. Service ở tên miền phải mang thông tin về xử lý nghiệp vụ, còn Service ở application có thể kết hợp gọi service ở domain name 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ể phân 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 bắt buộc model, ta thấy rằng model driven kiến thiết được nhắc đến trong DDD khá gần với Object Oriented Design, mà lại không giới hạn.

Trong ứng dụng phần mềm, các đối tượng domain object liên tục được tạo ra, biến đổi, lưu lại lại, nên 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 chung 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ố gắng đổi đối với phần tử vào 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 tiền về Aggregate thì car là aggrate của tire (bánh xe), wheel(vô lăng)..

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

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

3. Phong cách xây dựng ứng dụng dùng DDD

Các thiết kế viên hoàn toàn có thể quen với phong cách xây dựng MVC. Nhưng mà trong sách xanh có nói, sẽ là những phong cách thiết kế “ô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 xúc tích và ngắn gọn như sau: – UI( Tầng giao diện) : phụ trách cho hiển thị thông tin, dìm lệnh từ người tiêu dùng – Application( Tầng ứng dụng) : kết hợp các xử lý. Xem xét là ko chứa xúc tích nghiệp vụ ở đâ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 mô hình biểu diễn nghiệp vụ của hệ thống. Thể hiện xúc tí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 liêu trọ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 những thư viện bên ngoài.. Phần này đặc biệt quan trọng quan trọng cho những lập trình viên. Việc tùy chỉnh và giữ vững những quy tắc giao tiếp giữa các lớp, phân chia trách nhiệm phù hợp là điều kiền nên thiết đảm bảo kiến trúc hệ thống. Evan có giới thiệu khá chi tiết về quy mô 4 tầng vào sách của mình kèm ví dụ tham khảo liên kết ở cuối bài. Dường như hiện xã hội DDD cũng lời khuyên kiến trúc văn minh có thể dùng với DDD là Hexagonal Architecture tuyệt Port & adapter. Hy vọng có lúc được phân tách 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 khi phát triển dự án, từng bước hoàn thiện tế bào hình, xây dựng những ứng dụng lớn. Ở đó DDD đưa ra những lưu ý thiết thực mang đến quá trình cách tân và phát triển với các best practices về: – Tái cấu tạo liên tục – gia hạn tính toàn diện của mô hình

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

4. Vài gớ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 cùng phức tạp, vì thế nó áp dụng nhiều design patterns và các best practices. Việc làm chủ những khái niệm này là không dễ và đòi hỏi nhiều khiếp nghiệm. Ngoài ra cả team đều phải hiểu và 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 không phải là một chính sách, quyết trung tâm của doanh nghiệp thì cũng gặp nhiều khó khăn để áp dụng.

Xem thêm: Iphone 6 Plus Và 6S Plus Khác Nhau Chỗ Nào Sẽ Tốt Hơn? Khác Biệt Giữa Iphone 6S Plus Và Iphone 6 Plus

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