Tôi đã có một nội dung bài viết về Domain Drive Development (DDD) – First thought để “đặt vấn đề” mang đến DDD, các bạn cũng có thể tham khảo ở kia trước. Trong phạm vi nội dung bài viết này, tôi sẽ tham khảo và diễn đạt lại từ bài viết Domain-Drive Design của người sáng tác herbertograca.
Bạn đang xem: Domain driven design là gì
Domain-Drive Design bởi Eric Evans tạo nên trong cuốn sách khét tiếng của ông về Domain-Driven Design: Tackling Complexity in the Heart of Software, xuất phiên bản năm 2003. Cuốn sách của Eric Evans là chìa khóa bằng lòng hóa các khái niệm phân phát triển ứng dụng hiện nay.

Eric Evans, 2003
BOUNDED CONTEXTS
Trong một áp dụng doanh nghiệp, tất cả thể có rất nhiều model, những khái niệm cũng giống như số lượng và size của team thao tác làm việc trên codebase là hết sức lớn. Điều này mang lại cho họ hai vấn đề:
Các developer thao tác trên codebase càng lớn thì càng khó thừa nhận thức cùng hiểu đúng về rất nhiều gì đông đảo đoạn mã vẫn làm, và bởi vì đó rất có thể tạo ra bug, gây khó khăn trong việc debug, hiểu đúng với ra quyết định được gia công theo cầm nào.Các những developer thao tác làm việc trên cùng một codebase, càng trở ngại hơn để hợp tác và tất cả một tầm nhìn tổng thể về chuyên môn và nhiệm vụ của ứng dụng.Nói bí quyết khác, sẽ là 2 vụ việc lớn cần giải quyết và xử lý khi thao tác với các ứng dụng tầm kích thước enterprise.
Giải pháp thông thường cho một sự việc lớn là chia bé dại nó thành đông đảo phần nhỏ tuổi hơn, hay nói một cách khác là “bounded contexts”. Chỗ mỗi phần phục mang đến những đối tượng người tiêu dùng người cần sử dụng khác nhau. Nói giải pháp khác, vào 1 khối hệ thống phần mượt doanh nghiệp, vị trí mà hệ thống sẽ ship hàng cho cực kỳ nhiều đối tượng người sử dụng khác nhau, việc bọn họ nên làm cho là chia bé dại hệ thống kia ra thành phần nhiều hệ thống nhỏ dại hơn, riêng biệt về nhiệm vụ, và đối tượng người dùng người dùng. Ví dụ khối hệ thống nhân sự, kế toán, tiền lương. Từng hệ thống có 1 ngữ cảnh riêng call là “bounded contexts”, địa điểm mà nó hệ thống con kia chỉ có hiểu biết về ngữ cảnh, nghiệp vụ nó đảm nhiệm.
Two subsystems commonly serve very different user communities.
Eric Evans 2014, Domain-Driven design Reference
Các bounded contexts xác minh một ngữ cảnh áp dụng 1 phần riêng biệt của mô hình nghiệp vụ. Bài toán cô lập này có thể đạt được bằng phương pháp tách những logic kỹ thuật, tách biệt codebase, bóc biệt giản thiết bị cơ sở tài liệu (database schema) cùng về tổ chức triển khai team. Nút độ xa lánh bounded context, như hay lệ, nhờ vào vào thực trạng thực tế: yêu cầu và khả năng bọn họ có.
Một điểm thú vị, trên đây không phải là một khái niệm hoàn toàn mới. Ivar Jacobson sẽ viết về các khối hệ thống con (subsystems) vào cuốn sách của bản thân (Object-Oriented Software Engineering: A Use Case Driven Approach), quay trở lại vào năm 1992, mười một năm trước Eric Evans!
Ivar Jacobson, 1992
Khi đó, ông đã bao gồm một vài ý tưởng rất cụ thể về chủ đề này:
Hệ thống do vậy bao gồm một số các khối hệ thống con rất có thể chứa các khối hệ thống con của chính nó. Ở dưới thuộc của phân cấp vì vậy là các đối tượng phân tích (analysis objects). Các hệ thống con là một phương pháp để cấu trúc khối hệ thống cho việc phát triển và bảo trì.Nhiệm vụ của các khối hệ thống con là gói gọn các đối tượng sao để gia công giảm đi sự phức tạp.Tất cả các đối tượng người tiêu dùng đảm nhiệm những phần ví dụ của chức năng sẽ được đặt trong cùng một khối hệ thống conMục đích là để sở hữu một đính thêm kết chức năng mạnh mẽ trong một subsystem và một sự liên kết lỏng lẽo giữa các subsystem (ngày ni được call là low coupling and high cohesion)ANTI-CORRUPTION LAYER
Một Anti-Corruption Layer cơ phiên bản là một middleware giữa hai khối hệ thống con. Nó được sử dụng để cô lập hai khối hệ thống con, tạo cho chúng nhờ vào vào layer này cầm cố vì phụ thuộc vào trực tiếp vào nhau. Bằng cách này, nếu chúng ta tái cấu tạo hoặc nạm thế hoàn toàn một vào các khối hệ thống con thì chúng ta sẽ chỉ phải update layer này nhằm các hệ thống con khác không bị ảnh hưởng.
Điều này quan trọng hữu ích khi tất cả một hệ thống mới mà bọn họ cần nên tích hợp với một khối hệ thống có sẵn. Để không để những hệ thống cũ chịu sự tác động từ việc thêm new các hệ thống con mới, bọn họ tạo ra một Anti-Corruption Layer sẽ kiểm soát và điều chỉnh API của hệ thống cũ đến các nhu yếu của khối hệ thống con mới.
Có 3 mối quan tâm chính:
Điều chỉnh các API hệ thống con với rất nhiều gì những client subsystems cần;Translate data và commands giữa các hệ thống con;Thiết lập hội đàm (communication) theo một hoặc những hướng, trường hợp cầnEric Evans, 2003
Đây là một trong những kỹ thuật được sử dụng phù hợp khi bọn họ không kiểm soát điều hành một hoặc toàn bộ các hệ thống con, mà lại cũng hoàn toàn có thể sử dụng nó khi chúng ta kiểm soát tất cả các hệ thống con liên quan, trong cả khi chúng có phong cách thiết kế tốt nhưng đơn giản và dễ dàng có các mã sản phẩm rất khác nhau và họ muốn ngăn ngừa sự thất thoát từ mã sản phẩm này sang model khác (thay thay đổi một hệ thống con để tương xứng với nhu cầu của một hệ thống con khác).
SHARED KERNEL
Trong một trong những trường hợp, bất chấp mong ý muốn của bọn họ để có các thành phần tách bóc biệt trọn vẹn và bóc tách rời, vẫn có một số trong những trường phù hợp buộc ta phải bóc tách một số domain code ra để chia sẻ cho nhiều component khác sử dụng.
Điều này sẽ cho phép các component vẫn giữ được tính phân bóc tách và chủ quyền với những component khác mặc dù sử dụng thông thường những mã chia sẻ cùng (shared code), ta gọi những mã chia sẻ này với cái thương hiệu “shared kernel”.
Trường thích hợp ví dụ, với các events được kích hoạt vì một component với lắng nghe do một hoặc một vài component khác. Và tựa như cho những service interfaces and thậm chí là những entities.
Tuy nhiên, bắt buộc giữ phần Shared Kernel này càng nhỏ càng tốt, và cẩn thận khi chuyển đổi nó vì chúng ta có thể một phương pháp vô tình gây tác động đến những chỗ khác đang sử dụng nó. Điều đặc biệt là mã trong Shared Kernel sẽ không còn nên bị đổi khác nếu không có sự tham gia cùng hiểu biết của toàn bộ các nhóm phát triển khác thực hiện nó.
GENERIC SUBDOMAIN
Một Subdomain là một trong những phần rất biệt lập của domain. Generic Subdomain là một trong những Subdomain không liên quan đến áp dụng của bọn họ mà có thể được sử dụng trong ngẫu nhiên ứng dụng làm sao tương tự.
Vì vậy, nếu có một ứng dụng có 1 phần của nó là về finance, tất cả lẽ bạn có thể sử dụng một tủ sách finance hiện tất cả trong ứng dụng. Mà lại dù sao đi nữa, trong cả khi ko thể sử dụng thư viện hiện tất cả và yêu cầu xây dựng riêng biệt của bọn chúng ta, ví như nó là 1 trong những Generic Subdomain thì đó chưa hẳn là chuyển động cốt lõi với nó cần phải được đánh giá là cần thiết nhưng không quan trọng. Đây không phải là phần quan trọng nhất trong áp dụng nên không hẳn là địa điểm các chuyên gia giỏi độc nhất nên tập trung và thậm chí phải rõ ràng bên phía ngoài mã nguồn chính, nó rất có thể được cài đặt với một công cụ làm chủ sự nhờ vào (dependency management tool).
KẾT LUẬN
Các định nghĩa DDD tôi đã chọn để tiếp cận ở chỗ này là, một lượt nữa, hầu hết về single responsibility, low coupling, high cohesion, isolating xúc tích để vận dụng của bọn họ trở yêu cầu nhất quán, dễ dãi và nhanh chóng hơn để chuyển đổi và mê thích ứng với nhu cầu của doanh nghiệp.
Xem thêm: Chế Độ Fridge Là Gì, Nghĩa Của Từ Fridge, Hướng Dẫn Cách Chỉnh Nhiệt Độ Tủ Lạnh
SOURCES
1992 – Ivar Jacobson – Object-Oriented Software Engineering: A use case driven approach
1996 – Robert C. Martin – Granularity
2003 – Eric Evans – Domain-Driven Design: Tackling Complexity in the Heart of Software
2014 – Eric Evans – Domain-Driven thiết kế Reference
Đây là bài viết trong loạt nội dung bài viết về “Tổng quan lại về sự cải cách và phát triển của phong cách thiết kế phần mềm“. Đây là loạt nội dung bài viết chủ yếu giới thiệu về một số mô hình kiến trúc ứng dụng hay nói đúng hơn là việc phát triển của chúng qua từng giai đoạn, thông qua đó giúp họ có tầm nhìn tổng quát, up-to-date cùng là roadmap để bắt đầu hành trình đoạt được (đào sâu) thế giới của những bạn dạng thiết kế với phương châm là phần đa kỹ sư và bản vẽ xây dựng sư phần mềm đam mê cùng với nghề.