当前位置:网站首页>Why don't I recommend Uncle Bob's clear architecture?

Why don't I recommend Uncle Bob's clear architecture?

2021-05-04 12:37:05 Jiedao jdon

Clear architecture Clean Architecture, Also known as clean Architecture 、 Clear architecture 、 Clean architecture 、 Clean architecture , He is a famous software engineer Robert C Martin A kind of The way to structure cleanly . The following is the main idea of the original text , Click on the title to enter .

Clear architecture doesn't meet my expectations in many ways . Although Mr. Martin showed great enthusiasm for it , But the organization of clear architecture is poor , Lack of examples , And remain silent about the use of existing systems . The author missed an important opportunity to teach us when and how to apply these courses to our own systems .

Clear architecture is a poorly organized book

It takes a long time to get to the core of this book , About design paradigm ( structured , Object oriented and function oriented ) It seems that the chapter of is particularly inappropriate and unnecessary .

About SOLID The chapter on principles is good . I'm glad to see these principles broken and explained very well . I find it interesting to think about their applicability to system architecture . But Uncle Bob came up with something like hard rules SOLID principle , This principle makes me misunderstand . in fact , I'm pretty sure it's against SOLID The system of principles will be a huge chaotic system .

however , The first 137 This section of the page is very important :

The main purpose of architecture is to support the life cycle of the system . Good architecture makes the system easy to understand , Easy to develop , Easy to maintain and easy to deploy . The ultimate goal is to minimize the life cost of the system and maximize the productivity of the programmer .

It's a good idea , Why didn't Uncle Bob put it in the first chapter ?

There are not enough examples

There are few examples in this book . The first 33 This chapter contains an example of a video sales e-commerce application . I've been thinking about how to apply these concepts to my own system .

The appendix tells how Uncle Bob put forward SOLID The story of principles and clear rules of Architecture . It contains examples of past projects . I think this is the most interesting part of the book .

There is no mention of improving the architecture of existing systems

Most developers spend most of their time on existing systems . therefore , I hope this book will provide suggestions for improving the existing system . But the book is clearly silent on this issue .

How to create a clean 、 Clear architecture ?

In the first half of the book , You will learn by following SOLID Principles create a clear framework , Decompose the system into components within the system boundary . At the end of the book , In the 228 page :

The purpose of this example is to show that architectural boundaries exist anywhere . As an architect , We have to be careful when we need them . We also have to realize that , These boundaries are expensive when fully implemented .

meanwhile , We have to realize that , When you ignore these boundaries , Even in the presence of a comprehensive test suite and refactoring rules , They are also very expensive to add later .

So what do we architects do ? The answer is not satisfied . One side , Some very smart people have told us over the years , We shouldn't predict in advance what needs to be abstracted . This is a YAGNI Idea :“ You don't need it .”  This message is intelligent , Because over engineering is often worse than Engineering . however , On the other hand , When you find that you really need an architecture boundary that doesn't exist before , The cost and risk of adding such boundaries can be very high .

So you have to see the future . You have to guess intelligently . You have to weigh costs and determine where the architecture boundaries are , Which should be fully implemented , Which parts should be implemented , What should be ignored .

therefore , He said ( More than half of this book ), We should decide to put the concept of boundary in our system . Such borders can be everywhere . It's confusing , Right ?

(banq notes : I understand DDD You know , This kind of boundary is a kind of context boundary , And philosophically , It's a logical boundary , The word world itself contains boundaries , Boundary is the symbol between subjective and objective , It's a kind of ternary world view , It's hard for people with dualism and monism to understand .)

What's missing from this book

therefore , If the ultimate goal of software architecture is to minimize the life cycle cost of the system , So should architecture books help architects make these decisions ?

The book left me many unanswered questions . Where is the economic discussion of options ? How to find the best architecture for my system ? Where is the research ?

How to determine whether horizontal layering or vertical slicing or other methods can minimize the life cycle cost of the system ? perhaps , If I don't have a clearly defined architecture hierarchy , How do I decide which layering strategy will minimize my life cycle costs ?

I have more questions . If you have enough time to improve the architecture of the existing system , Where should you put your efforts ? Is it always a good idea to separate the database from the business logic ?(banq notes : In the actual system, most of them use database to realize business logic , So the database Oracle Etc. and business logic are mixed together , and DDD To make you understand that , But separating is a revolutionary job , Generations work hard .) What advice should you follow ? Which recommendations depend on the system ?

send Clean Architecture More valuable details

stay Code Complete in ,Steve McConnell Reliability is discussed , reliability , correctness , Maintainability , The trade-off between different non functional requirements such as readability . He explained how some needs change together and conflict with others (banq notes : The logical contradiction between the concepts of requirements , It is necessary to achieve logical consistency , You can't wait until the software is implemented , It's expensive ). For the architectural decisions discussed in this book , I would have liked to see something similar .

In a clear architecture , Project scale , Team size , The consequences of project failure , The expected code lifetime and other important factors are not emphasized as the driving factors of the architecture .

The real meaning of this book

Use a figurative metaphor to illustrate the meaning of this book :

Imagine , You're building desktop computers for the consumer market ( Office computers, for example ). You can choose hardware , And then you're going to write a system for the whole thing ( Include hardware , operating system , The driver , Applications , everything ).

Can you write a monolith system ? Can you write a huge one block program ? For example, using a spreadsheet to encode , Does it know how to choose the disk type for your computer ? You can imagine adding... Anywhere “if” sentence , So that when you have SATA Do you want to perform an operation while driving ? If you have SCSI Does the drive perform another operation ?

It will be a nightmare , Right ? So what's the solution ? framework ! Your spreadsheet code should not know which disk you are using .

So what is the boundary in a computer ?

If you look at your computer , Then you will find out : There's embedded software in the mouse , Can communicate with your operating system . However , Details are hidden in your application . Your spreadsheet accepts standardized input , I don't know or care what kind of mouse or disk you are using . And then when someone invented a new input device like the touchpad , It will automatically work with spreadsheets .

This is just a boundary of your computer . You might come up with hundreds of . You can assign different teams to deal with different parts of the system . You can create or adopt different specifications for various ways in which different components interact .

You might say at this point ' Uh '. Obviously , Every time the hardware changes , You don't want to change and recompile spreadsheets . Maintenance will be a nightmare .

Borders are your friends ( If you use them correctly )

It's easy to see the hardware boundaries . however , The same logic of hardware boundaries applies to software boundaries . Software boundaries are hard to see .

therefore , You can start by displaying the spreadsheet on the screen . You may want to save it to disk , Save it as PDF, Or save it as CSV Or print . therefore , One boundary in a spreadsheet program might be having an internal data structure that represents each spreadsheet . Then pass the structure to different code , Display... In the desired format , Save or print it .

If you decouple the data structure completely from its display , How to save or print , Then you can add... In the future “ Save to XML” New features such as , This eliminates the need to browse all the code associated with the spreadsheet data structure . If the spreadsheet data structure is millions of lines of code , You can imagine how easy it would be to add new features !

That's what Uncle Bob is trying to tell us in this book . You can use SOLID Principles create boundaries in the system , Hide the implementation details , Reduce complexity , And help you reduce the total life cycle cost of the system .

Better software architecture book :

in many ways ,Martin Fowler  Enterprise application architecture pattern of Far better than Clean Architecture.Fowler Describes the patterns he has repeatedly observed in enterprise applications . He gave a simple example , If every pattern , Describe how it works , And where to use it . I find Enterprise application architecture pattern It's very readable and works on my system .

 

版权声明
本文为[Jiedao jdon]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/05/20210504123224190r.html

随机推荐