I recently finished talking about Architecture, which I have recommended many times in my wechat moments. I recommend it not because it’s written beautifully or because it’s a great book, but because it answers a lot of questions I’ve been asking about software engineering, architecture, and software itself.
Some people read it on my recommendation and later said it was a wordy 50 pages book, all of which can be found in the first three chapters of software engineering, and software engineering and architecture is definitely not covered in 50 pages.
This paragraph reminds me of my previous experience as a programmer. I have also read books related to software engineering. Perhaps MY understanding is too poor to combine the contents in the books with the actual software development, and I seem to understand the contents in the books but do not know how to apply them to the software development work. Of course, MY background is not systematic software engineering related education, probably has something to do with this.
Until I read this book, and I met you. “Software is virtual people in a virtual world doing jobs for real people, except that these virtual people don’t have the consciousness or personality to operate them like muppets.” This phrase stuck in my head as I read the book.
Everything in the world has a life cycle, ranging from the universe to the particle, from the physical world to the spiritual world. Since software is a virtual human, it should also have its own life, its own life cycle.
People’s job is to finish his own life in their own life cycle tasks, these tasks have important is not important, have the existential must, have an impact on the quality of life, people in life there are all kinds of requirements, these requirements will constitute the person’s life at different stages of different scenarios, different transaction.
These transactions themselves take on a life cycle of their own. Therefore, from the concept of human life cycle is divided into different life cycle by various scenes, tasks, roles and identities, including core life cycle and non-core life cycle, some must be done by oneself, and some can be handed over to others.
In human history, as work became more and more complex and tasks became more and more complex, human collaboration became more and more elaborate, and then division of labor came into being, and division of labor is the division of human life cycle resulting from collaboration. This is so specific that everyone can do what they are good at, thus generating surplus, which can then be exchanged to meet their own needs. The history of human division of labor and cooperation is the history of life cycle segmentation.
The same is true in the virtual world of software, which is a mapping and abstraction from the real world to the virtual world. The operation of software is also a process of division of labor and cooperation between virtual people composed of codes. Since there is division of labor and collaboration, it is necessary to clarify their responsibilities and powers, to ensure the equality of power and responsibility between each virtual person.
In order to achieve the equality of power and responsibility between virtual people, we must first ensure the equality of power and responsibility in the organizational structure of the real world. Only in this way can we complete the mapping from reality to virtual world. I wonder how many people have encountered the phenomenon of unequal power and responsibility in their work and life, and even the phenomenon of responsibility and no power.
This disparity of responsibility makes it difficult to complete the mapping from reality to virtual, and the related development work must be quite painful. Therefore, the word architecture is not necessarily a term for the technical field, but a generalization of the relationship between people, things, things, rights and responsibilities in the real world, as well as the division of labor and collaboration between people.
In the development process of any thing, there is always a life cycle of segmentation and merger. One of the examples in the book is the human immune system. The immune system is an essential part of keeping people alive, but there are some people whose immune system can’t do its job properly due to nature or nurture, and they won’t survive for long before drugs are available.
There are now immune drugs that can take over some of the functions of the immune system and extend their lives. In the future, there may be nano-robots that can completely replace the immune system, and these foreign objects can do the immune function for them.
In fact, this situation is the segmentation of the core life cycle of human survival. From the immune system as an integral part of the core life cycle of human life, to the separation from the core life cycle.
Software development, for example, has gone from an industry where requirements, modeling, development, testing, operations were all software engineers, to specialized people doing all of that.
Now the development of software engineering appears that the responsibility of development, testing, operation and maintenance has returned to the role of software engineer. Software engineering has gone through a cycle of life cycles from shard to merge.
Made clear the concept of life cycle will be realized, with the development of things, it is part of the function from the core of the life cycle segmentation, constructs the new life cycle, can help the things clear its core, clarify the responsibilities of their life cycle and power, to spend more time on things you’re good.
Along with the new organizational and software architecture. New organizational structure is inevitably accompanied by new benefit adjustment and influence on stakeholders. Therefore, the organizational structure in the real world is often more difficult to change, especially in mature and stable organizations, because these changes will move some people’s cheese, while the organizational structure in the real world will affect the software architecture in the virtual world.
If the organizational structure of the real world is not changed, but trying to change the software architecture to adapt to the situation of the real world will inevitably result in the unequal rights and responsibilities of virtual people and the abstraction of virtual people and the real world is inconsistent. Good structure, efficient execution must have a clear and equal division of rights and responsibilities. The division of corresponding responsibilities is accompanied by the corresponding separation and delegation of power.
The organizational structure of the real world is hierarchical and tree-like, and even everything in the real world has such relationships. Animal embryo development is also a process of gradual stratification and division of rights and responsibilities. Evolutionary relationships in biology are also a tree structure. The whole universe is also a tree. The software architecture mapped to the virtual world is also hierarchical and tree-like.
Discover new lifecycles and create new entities from the separation of different responsibilities and the merging of similar responsibilities. Keep iterating this process, gradually clarify the rights and responsibilities of each entity, and find the efficient and low cost, eliminate the inefficient and high cost. This is the iterative process of software and the process of architectural evolution. Software architecture is inherently designed, evolving, changing, and making trade-offs.
Once you understand this, you can clearly distinguish the layers of access code, business code, storage code, glue code, and what roles they should play. Instead of all the code being mixed together and seemingly following the classic MVC hierarchy, the business code actually appears in controller/ Service /DAO. There is no clear division.
The correct thing to do is for the controller to do the access logic; The DAO completes the storage logic; Service implements glue logic, connects the preceding and the following, uses DTO transform to access parameters, executes business logic, invokes DAO mapping to store model, and uses DTO transform business processing results into response results, and business logic is implemented in business model.
If the business logic is implemented with business data, it is the congestion model. Further, it is the DDD pattern. Only in this way can a clear division of software layers be completed, with each layer performing its own duties and equal rights and responsibilities. Otherwise, it is a big ball of mud. With this in mind, it becomes clear that business transactions are not the same thing as relational database transactions and that business transactions are dependent on relational database transactions to ensure data integrity.
It is perfectly possible to separate the two and implement them in a more businesslike way, even if the business itself has a mature solution to ensure data integrity and no longer needs to rely on relational database transactions. In business, the dependency on ACID property of relational database transactions is no longer necessary. Therefore, the dependency on ACID property of database is no longer necessary. You can choose an appropriate storage scheme according to business needs.
Business models and implementations are no longer dependent on the technical characteristics of specific solutions, which decouples business from technology and makes horizontal scaling easier. Lateral extension is now found to be a fundamental property of nature. Innumerable elementary particles make up atoms, and innumerable atoms make up a concrete macroscopic object. One person is not enough to add more people. If the scale of a system reaches a bottleneck in horizontal expansion and can no longer be improved by simply increasing the number, there must be some unreasonable factors in the organizational structure of the system.
It is natural to talk about the relationship between business and technology. As mentioned above, software is a mapping abstraction of the real world, where virtual people do some work instead of natural people. To do good software, you have to understand the business, and the deeper you understand the business, the more likely you are to create great software.
In this process, the architect acts as a bridge between the real world business and the virtual world software. His job is to map the natural person performing the business from the real world to the virtual person in the software world. Architects naturally have a deep understanding of the business and a deep understanding of technology. Build the right model for the business, choose the right technology for the model, and finally implement it.
However, the real world is too complex. As business develops, software becomes larger and more complex, and it is difficult for one person to do all the architecture work, architect teams are created and architects have more detailed division of labor. The architect’s life cycle has been split accordingly, resulting in business architecture, application architecture, and system architecture.
Architects naturally need functional equivalents of authority in order to be able to implement their architectural ideas. Therefore, the architect is not a purely technical position, but a managerial position, and the requirements of the architect in different roles are different. Talking about Architecture has given me a new understanding of software engineering, architecture, business, technology, and the relationships between people, things, things, rights, and responsibilities, or perhaps these understandings have been developing with my years of experience in the industry, and this book has finally opened my eyes.
I think this book is especially suitable for those who are new to software engineering or who are hovering in front of software engineering. It is also suitable for people who have been in the industry for many years and are still troubled by many problems such as software engineering and architecture ideas. In addition, I think it is also worth reading for product managers, which can help them understand some software engineering ideas and reduce communication barriers with the technical team.
But if you’re not a beginner in software engineering and don’t have any development experience, I don’t think this is a good book to read, and it can be even more confusing. If you already have a deep understanding of software engineering and architecture ideas and have been comfortable with them for years, this book is not for you either, or, like the person at the beginning of this article, you will find it empty.
PS. After I recommended this book many times in my wechat moments, Guo Lei invited me to write and recommend this book. At the beginning, I refused, because I was not confident in my writing level, and I was afraid that I could not explain my feelings and harvest from reading this book because of my poor writing. Thanks to Guo Lei’s encouragement, I finished my first book review, which is also my summary of the book and my own summary of many years in the industry.