Difference Between High Level Design Là Gì, Hld Định Nghĩa: Thiết Kế Cao Cấp

Bạn đang quan tâm đến Difference Between High Level Design Là Gì, Hld Định Nghĩa: Thiết Kế Cao Cấp phải không? Nào hãy cùng TTTD đón xem bài viết này ngay sau đây nhé, vì nó vô cùng thú vị và hay đấy!                        

Difference Between High Level Design Là Gì, Hld Định Nghĩa: Thiết Kế Cao Cấp
Photo by Austin Distel on UnsplashBackgroundIn the software development process, in this case, significant scope project development. That has many teams involved, and sometimes there is some missing link between the member for understanding the feature. The absent link cause by there is no base understanding for each team. That is why documentation is needed to standardize the development process. A High-Level Design can be a way to get all team understanding of how the overall solution that will be implemented.

Bạn đang xem: High level design là gì

High-Level design can provide a framework or guidance for across the team the get a better understanding of the feature. This documentation can drive the detailed design to follow the overall solution. To create a High-Level Design there are many approaches to start with. The simple way to do it is to create a diagram to represent the solution. The document will not contain a full explanation, like what framework to be used. But more like a general flow on how the process would be and what technical solution that we needed to complete the requirement.

The Solution

Gather RequirementThe first thing to do is to get the full requirement from the business team. Regardless they already make the User Story (List of requirement in a story form by user perspective), we also need to get a better understanding of the requirement. To get a solid base of understanding requires a discussion of the requirement with the Product Owner, which in that session, we can run through the requirement one by one.

We usually will look at the story, and the UI design (if already there) briefly take a look at:

Business rulesFront EndData flowAPI standpointDatabaseExternal system integration

In the session, we can roughly discuss all the points and our perspectives from the technical team to the business team. Then there might be a change in their requirement and design based on how the session going because we don’t want any funny requirement that in the end cannot be implemented in our application.

XEM THÊM:  Nghĩa Của Từ Soothe Là Gì ? Nghĩa Của Từ Soothes Trong Tiếng Việt

Get High-Level FlowAfter getting clear about the requirement and high-level flow, it is time to create a high-level design. First, We make a (System) diagram to design our solution. In our project, because we use Microservices architecture, we will define the use case as a service. We will create a relationship between service to create a general understanding of the service that will be used.

Second, we will create a diagram between the screen flow. In this diagram, we can get an overview of the general flow. We also put all the possible API (Application Programming interface), data flow, and external system integration. To create this diagram, we need to align the requirement and the design screen. Don’t forget to include all the decisions and logic between each flow. For High-Level Design, we only create a positive flow, or usually, we call this happy flow. Because first, we want to know the goal of the process.

System Diagram



System Diagram

In creating the System Diagram, we’ll have to see deeper from the technical standpoint. These days, we use separate Micro Services for each feature. It will be based on how the technical team doing the work. So for this case you have to understand already when we will need to create a new Microservice and when it is not. This understanding will be variant on how the organization work and you as the one to develop the solution. There will be a lengthy discussion across the team before and after creating the solution. But the main point here is to get the answer first on how we will complete the requirement.

XEM THÊM:  Tư Sản Mại Bản Là Gì

Xem thêm: Thông Tin Tiểu Sử Diễn Viên Tiến Luật Bao Nhiêu Tuổi, Thông Tin Tiểu Sử Diễn Viên Tiến Luật

Can we use existing Micro Services to handle the requirement?How many new Micro Services that we need?Is there any external system that needs to be integrated?

Based on this question we need to come up with the answer by the system diagram. We can draw it like this, in this case, is a mobile application, by connecting it to the require Micro Services and what external system that we need.

High-Level Design



High-Level Design

After creating the System Diagram, we can continue work on the High-Level Design. In this diagram, it will be much better if the UI/UX already finish their design. So we can recreate their flow with plus the technical solution that we come up with. To doing so, start with the positive flow, where is the entry point, draw the process until when the flow is ended. Add the decision and logic for each screen. After that add the solution, what API that we need to call, what Microservice that we use, what data we need to pass for each screen. We will use this naming convention for the API. But it will be based on how the technical team will write it.


API Naming

The next step is to add the external system that we needed for each API. If you already know the system name you can put there specifically, either way, you can put the function first like “Payment Gateway” etc.

Later after you finish the positive flow, we can design the negative flow. Practically we need to see all the possible handling for the flow. Like when the API call is failed, business error, external system down, or cannot be reached. All that can be added here in the High-Level Solution, or we can keep it later for the Detailed Design. At least, we can identify first how the handling would be looked like.

XEM THÊM:  Nhạc Phạm Đình Thái Ngân Sinh Năm, Nhạc Phạm Đình Thái Ngân


By doing this organization now will have base documentation on how the feature will be. We can present our solution upfront to explain how the feature work and what we need to implement. The technical team can get a bigger picture of the feature and start thinking of the implementation. From a business team standpoint, they can get a functional diagram that explains how the requirement will be built. When we can get all team to understand the big picture we can collect the feedback faster on how complex the feature will be and of course how long it will take. This documentation and process will remove the missing links and can get all the team on board with the same goal; collaboration from each team require to produce a quality and faster implementation.

Xem thêm: Cấu Trúc Của Chủ Từ Trong Tiếng Anh Là Gì, Chủ Ngữ Và Động Từ Trong Tiếng Anh (Tổng Hợp)

Although creating a High-Level Design is not a one-time process, you need to iterate the process over and over again through many cases and scenarios. Because you want this as a foundation of the feature or application, you want to build. Get experience by discussing with many functions of the team. Even you can use High-Level Design to communicate with management on how the solution will be. In the end, all member from the business team or technical team can go back to this to see the solution, how the feature work, what do we need, and what the goals of the feature or application.

Chuyên mục: CUỘC SỐNG

Vậy là đến đây bài viết về Difference Between High Level Design Là Gì, Hld Định Nghĩa: Thiết Kế Cao Cấp đã dừng lại rồi. Hy vọng bạn luôn theo dõi và đọc những bài viết hay của chúng tôi trên website TTTD.VN

Chúc các bạn luôn gặt hái nhiều thành công trong cuộc sống!

Trả lời

Email của bạn sẽ không được hiển thị công khai.