Domain driven design là gì

Tôi đã có một nội dung bài viết về Domain Drive Development (DDD) – First thought để “đặt vấn đề” mang lại DDD, các chúng ta có thể tham khảo ở kia trước. Vào phạm vi bài viết này, tôi sẽ xem thêm và biểu đạt lại từ bài xích viết Domain-Drive Design của tác giả herbertograca.

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

Domain-Drive Design bởi vì Eric Evans tạo thành trong cuốn sách nổi tiếng của ông về Domain-Driven Design: Tackling Complexity in the Heart of Software, xuất bạn dạng năm 2003. Cuốn sách của Eric Evans là chìa khóa thừa nhận hóa các khái niệm phát triển phần mềm hiện nay.

Eric Evans, 2003

BOUNDED CONTEXTS

Trong một vận dụng doanh nghiệp, có thể có rất nhiều model, những khái niệm cũng giống như số lượng và form size của team thao tác trên codebase là siêu lớn. Điều này đem đến cho bọn họ hai vấn đề:

Các developer thao tác trên codebase càng lớn thì càng khó nhấn thức cùng hiểu đúng về các gì hầu như đoạn mã đã làm, và bởi vì đó rất có thể tạo ra bug, gây trở ngại trong vấn đề debug, đọc đúng và ra quyết định được gia công theo cầm nào.Các các developer làm việc trên và một codebase, càng trở ngại hơn để hợp tác ký kết và có một tầm nhìn bao quát về nghệ thuật và nghiệp vụ của ứng dụng.

Nói phương pháp khác, đó là 2 vấn đề lớn cần giải quyết khi thao tác làm việc với những ứng dụng tầm kích thước enterprise.

Giải pháp thông thường cho một vấn đề lớn là chia nhỏ dại nó thành số đông phần nhỏ dại hơn, hay còn được gọi là “bounded contexts”. Chỗ mỗi phần phục cho những đối tượng người tiêu dùng người sử dụng khác nhau. Nói phương pháp khác, trong 1 hệ thống phần mượt doanh nghiệp, chỗ mà khối hệ thống sẽ ship hàng cho vô cùng nhiều đối tượng người sử dụng người sử dụng khác nhau, việc họ nên có tác dụng là chia nhỏ hệ thống đó ra thành rất nhiều hệ thống nhỏ dại hơn, hiếm hoi về nhiệm vụ, và đối tượng người sử dụng người dùng. Ví dụ khối hệ thống nhân sự, kế toán, chi phí lương. Mỗi hệ thống có 1 ngữ cảnh riêng call là “bounded contexts”, chỗ mà nó hệ thống con đó chỉ gồm 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 văn 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 các logic kỹ thuật, tách biệt codebase, bóc tách biệt giản thứ cơ sở dữ liệu (database schema) và về tổ chức team. Nút độ xa lánh bounded context, như thường lệ, phụ thuộc vào vào tình trạng thực tế: nhu cầu và khả năng họ có.

Một điểm thú vị, phía trên không phải là một khái niệm hoàn toàn mới. Ivar Jacobson đã viết về các khối hệ thống con (subsystems) trong cuốn sách của chính bản thân mình (Object-Oriented Software Engineering: A Use Case Driven Approach), trở lại vào năm 1992, mười một năm kia Eric Evans!

Ivar Jacobson, 1992

Khi đó, ông đã bao gồm một vài phát minh rất ví dụ về chủ đề này:

Hệ thống vị vậy bao gồm một số các khối hệ thống con hoàn toàn có thể chứa các khối hệ thống con của bao gồm nó. Ở dưới cùng của phân cấp như vậy là các đối tượng phân tích (analysis objects). Các khối hệ thống con là một cách để cấu trúc khối hệ thống cho việc cách tân và 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 người sử dụng sao để làm giảm đi sự phức tạp.Tất cả các đối tượng người dùng đảm nhiệm các phần rõ ràng của chức năng sẽ được để trong cùng một khối hệ thống conMục đích là để sở hữu một lắp kết công dụng mạnh mẽ vào một subsystem cùng một sự links lỏng lẽo giữa những subsystem (ngày ni được call là low coupling and high cohesion) nên xuất sắc hơn bắt buộc được thực hiện bởi có một actor, vì đổi khác thường được gây ra bởi một actor.<…> bắt đầu bằng bí quyết đặt các đối tượng người dùng điều khiển vào một subsystem, và kế tiếp đặt các đối tượng người sử dụng thực thể liên kết ngặt nghèo (strongly coupled) và các đối tượng người tiêu dùng giao diện (interface objects) trong cùng một subsystem.Tất cả các đối tượng người sử dụng có gắn kết tác dụng mạnh mẽ (strong mutual functional coupling) sẽ tiến hành đặt trong và một subsystem <…>Liệu những đổi khác trong một đối tượng người dùng dẫn mang đến những biến đổi trong đối tượng kia? (Điều này hiện nay được điện thoại tư vấn là bề ngoài The Common Closure Principle – Classes được xuất bản bởi Robert C. Martin trong bài báo “Granularity” năm 1996, 4 năm tiếp theo cuốn sách Ivar Jacobson)Liệu bọn chúng có tiếp xúc với cùng một actor?Có yêu cầu cả nhị đều phụ thuộc vào vào một đối tượng người sử dụng thứ ba, ví dụ như một interface object hay 1 entity? Liệu một đối tượng thực hiện một số hoạt động trên đối tượng người dùng kia? (Điều này được gọi là chính sách The Common Reuse Principle – Classes, được sử dụng cùng nhau được đóng góp gói cùng mọi người trong nhà của Robert C. Martin trong bài báo “Granularity” năm 1996, 4 năm sau cuốn sách Ivar Jacobson)Một tiêu chí khác mang đến việc phân chia là phải tất cả ít thông tin trao thay đổi giữa các hệ thống con khác biệt càng xuất sắc (low coupling)Đối với các dự án lớn, rất có thể có các tiêu chí khác đến phân khối hệ thống con, ví dụ:Các nhóm phát triển khác nhau có năng lực hoặc nguồn lực khác nhau và rất có thể phân phối các công việc phát triển phù hợp (các team cũng có thể được tách bóc biệt về mặt địa lý)Trong một môi trường thiên nhiên phân tán, một khối hệ thống phụ rất có thể được yêu cầu ở từng logical node (SOA, website services với micro services) nếu như một sản phẩm hiện có có thể được áp dụng trong khối hệ thống này, điều này rất có thể được coi là một subsystem (các libraries mà hệ thống phụ thuộc vào, ví dụ như ORM).

Xem thêm: Ứng Dụng Hangouts Là Gì - Điểm Nổi Bật Của Ứng Dụng Đình Đám Nhà Google

ANTI-CORRUPTION LAYER

Một Anti-Corruption Layer cơ bản là một middleware giữa hai khối hệ thống con. Nó được áp dụng để cô lập hai khối hệ thống con, làm cho chúng phụ thuộc vào vào layer này núm vì phụ thuộc vào trực tiếp vào nhau. Bằng phương pháp này, nếu chúng ta tái cấu tạo hoặc nắm thế hoàn toàn một trong các khối hệ thống con thì họ sẽ chỉ phải update layer này nhằm các khối hệ thống con khác không bị hình ảnh hưởng.

Điều này đặc trưng hữu ích khi gồm một hệ thống mới mà chúng ta cần buộc phải tích hợp với một khối hệ thống có sẵn. Để không để những khối hệ thống cũ chịu sự ảnh hưở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ũ cho các nhu yếu của hệ thống con mới.

Có 3 mối ân cần chính:

Điều chỉnh những API hệ thống con với phần lớn gì các client subsystems cần;Translate data và commands giữa các khối hệ thống con;Thiết lập thương lượng (communication) theo một hoặc nhiều hướng, ví như cần

Eric Evans, 2003

Đây là một trong những kỹ thuật được sử dụng phù hợp khi họ không kiểm soát một hoặc toàn bộ các khối hệ thống con, cơ mà cũng hoàn toàn có thể sử dụng nó khi họ kiểm soát tất cả các khối hệ thống con liên quan, ngay 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ông giống nhau và họ muốn ngăn ngừa sự thất thoát từ model 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 khối hệ thống con khác).

SHARED KERNEL

Trong một vài trường hợp, bất chấp mong muốn của chúng ta để có những thành phần tách bóc biệt hoàn toàn và tách bóc rời, vẫn có một số trường hòa hợp buộc ta phải tách một số tên miền code ra để share cho những component không giống sử dụng.

Điều này sẽ được cho phép các component vẫn giữ được tính phân tách và chủ quyền với các component khác mặc dù sử dụng thông thường những mã share cùng (shared code), ta gọi các mã chia sẻ này với cái tên “shared kernel”.

Trường vừa lòng ví dụ, với các events được kích hoạt bởi một component với lắng nghe bởi một hoặc một số component khác. Và tựa như cho những service interfaces and thậm chí là các 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 trọng khi thay đổi nó vì chúng ta có thể một cách vô tình gây ảnh hưởng đến những nơi khác đang thực hiện nó. Điều đặc trưng là mã trong Shared Kernel sẽ không nên bị biến đổi nếu không tồn tại sự tham gia với hiểu biết của toàn bộ các nhóm trở nên tân tiến khác sử dụng nó.

GENERIC SUBDOMAIN

Một Subdomain là 1 phần rất khác hoàn toàn của domain. Generic Subdomain là một trong những Subdomain không tương quan đến ứng dụng của bọn họ mà hoàn toàn có thể được thực hiện trong ngẫu nhiên ứng dụng như thế nào tương tự.

Vì vậy, nếu có một vận dụng có 1 phần của nó là về finance, gồm lẽ bạn cũng có thể sử dụng một tủ sách finance hiện bao gồm trong ứng dụng. Nhưng dù sao đi nữa, trong cả khi ko thể thực hiện thư viện hiện tất cả và yêu cầu xây dựng riêng của bọn chúng ta, nếu như nó là 1 Generic Subdomain thì đó không phải là hoạt động cốt lõi và nó cần phải được coi là cần thiết nhưng ko quan trọng. Đây không phải là phần quan trọng đặc biệt nhất trong áp dụng nên không phải là nơi các chuyên viên giỏi tốt nhất nên triệu tập và thậm chí còn phải rõ ràng bên ngoài mã mối cung cấp chính, nó hoàn toàn có thể được cài đặt với một công cụ quản lý sự phụ thuộc (dependency management tool).

KẾT LUẬN

Các có mang DDD tôi đã lựa chọn để tiếp cận tại đây là, một lượt nữa, chủ yếu về single responsibility, low coupling, high cohesion, isolating ngắn gọn xúc tích để ứng dụng của bọn họ trở cần nhất quán, thuận lợi và gấp rút hơn để chuyển đổi và ham mê ứng với yêu cầu của doanh nghiệp.

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 design Reference

Đây là bài viết trong loạt bài viết về “Tổng quan lại về sự cải cách và phát triển của bản vẽ xây dựng phần mềm“. Đây là loạt nội dung bài viết chủ yếu ra mắt về một số mô hình kiến trúc phần mềm hay nói đúng hơn là sự việc phát triển của chúng qua từng giai đoạn, qua đó giúp họ có cái nhìn tổng quát, up-to-date và là roadmap để bước đầu hành trình chinh phục (đào sâu) quả đât của những phiên bản thiết kế với vai trò là đông đảo kỹ sư và phong cách xây dựng sư ứng dụng đam mê cùng với nghề.