A conversation shows you what the architect is doing ?, Architecture or something

A conversation shows you what the architect is doing ?, Architecture or something

(Programmer :) I want to become a software architect.
(Senior Architect) This is a good goal for a young engineer.
(Programmer: I want to lead a team and make all the important decisions about databases, frameworks, and Web servers.
(Senior Architect:) Well, if so, you don't have to become a software architect.
(Programmer :) of course necessary! I want to be a person who can make all the important decisions.
(Senior Architect :) this is good, but you have not listed which are the important decisions. What you said just now has nothing to do with important decisions.
(Programmer :) what do you mean? Isn't the database important? Do you know how much we spent on the database?
(Senior Architect) there may be many. However, the database is still not the most important.
(Programmer :) how can you say that? The database is the heart of the entire system! All the data is stored here. They are sorted, indexed, and accessed here. Without a database, the entire system would not work!
(Senior Architect: the database is just an I/O device. It provides some useful tools to sort, query, and generate reports. However, these tools are only accessories of the entire system.
(Programmer :) accessories? Incredible.
(Senior Architect :) yes, It is an accessory. Your system business logic may use these tools, but these tools are not an inherent part of the business logic. If necessary, you can replace these tools at any time, but the business logic is still the business logic.
(Programmer :) okay, but if we replace these tools, we have to re-implement the business logic.
(Senior Architect :) that's your problem.
(Programmer :) why?
(Senior Architect: You think the business logic depends on the database, but this is not the case. If your architecture is good enough, at least the business logic should not depend on the database.
(Programmer :) this is crazy. How can I create business logic that does not use these tools?
(Senior Architect: I didn't mean to use database tools for business logic. I mean they should not rely on these tools. The business logic should not know which database to use.
(Programmer:) if the business logic does not know anything about the database, how does it use these tools?
(Senior Architect): Dependency inversion. You need to make the database dependent on the business logic, rather than making the business logic dependent on the database.
(Programmer :) your words are confusing.
(Senior Architect: Is it confusing? I am talking about the software architecture. This is the principle of dependency inversion, allowing lower-level policies to depend on upper-level policies.
(Programmer :) that's even more confusing! Since upper-level policies (assuming you are referring to the business logic) need to call lower-level policies (assuming you are referring to the database), the upper-level policies should depend on lower-level policies, just like the caller dependent on the called. This is well known!
(Senior Architect: This is true at runtime, but we need to reverse the dependency during compilation. Do not reference the code of any lower-level policy in the code of the upper-level policy.
(Programmer :) please! They cannot be called without referencing code.
(Senior Architect: Of course you can call it. Object-Oriented Approach.
(Programmer: Object-oriented Modeling of the real world, combining data and functions into objects, and organizing code into an intuitive structure.
(Senior Architect) did they tell you this?
(Programmer: Everyone knows this. Isn't that obvious?
(Senior Architect. However, object orientation can be called without reference.
(Programmer :) well, how does it do it?
(Senior Architect: You should know that objects in the object-oriented system will send messages to other objects, right?
(Programmer :) yes, of course.
(Senior Architect) You should know that the message sender does not know the type of message receiver.
(Programmer :) it depends on the language used. In Java, the sender must at least know the basic type of the receiver. In Ruby, the sender knows that the receiver will certainly process the messages it sends.
(Senior Architect :) yes. However, in either case, the sender does not know the specific type of the receiver.
(Programmer :) well, yes.
(Senior Architect) So the sender can pass a function to the receiver to let the receiver execute this function, so that the sender does not need to know what type the receiver is.
(Programmer :) that's right. I understand what you mean. However, the sender still depends on the receiver.
(Senior Architect: Yes at runtime, but not at compilation. The sender's Code does not reference the receiver's code. In fact, the receiver's Code depends on the sender's code.
(Programmer :) ah! However, the sender will still rely on the receiver's class.
(Senior Architect :) it seems that the code is needed to be clear. I use Java to write some code. First, the sender code:
Public class Sender {
Private aggreger extends er;
Public Sender (Explorer r ){
Cycler = r;
}
Public void doSomething (){
Receiver. receiveThis ();
}
Public interface extends er {
Void receiveThis ();
}
}
(Senior Architect) below is the receiver code:
Public class SpecificReceiver implements Sender. extends er {
Public void deleethis (){
// Some interesting things will be done here
}
}
(Senior Architect) you can see that the receiver code depends on the Sender code, that is, SpecificReceiver depends on the Sender. At the same time, we can see that the sender Code does not know anything about the receiver code.
(Programmer :) you cheated. You put the receiver's interface into the sender's class.
(Senior Architect: You get started.
(Programmer :) What do you understand?
(Senior Architect: Of course, it is the architecture principle. The sender holds the interface that the receiver must implement.
(Programmer :) if this means that I want to use an internal class, then ......
(Senior Architect: Using Internal classes is only one method, and there are other methods.
(Programmer :) please wait. We initially discussed databases. What are the relationships between these databases?
(Senior Architect) let's take a look at other code. First, a simple business logic
Public class BusinessRule {
Private BusinessRuleGateway gateway;
Public BusinessRule (BusinessRuleGateway gateway ){
This. gateway = gateway;
}
Public void execute (String id ){
Gateway. startTransaction ();
Something thing = gateway. getSomething (id );
Thing. makeChanges ();
Gateway. saveSomething (thing );
Gateway. endTransaction ();
}
}
(Programmer: This business logic has nothing to do.
(Senior Architect) This is just an example. In actual implementation of business logic, there will not be many classes like this.
(Programmer :) okay. What is Gateway used?
(Senior Architect) it provides all data access methods for business logic. The following is its code:
Public interface BusinessRuleGateway {
Something getSomething (String id );
Void startTransaction ();
Void saveSomething (Something thing );
Void endTransaction ();
}
(Senior Architect) Note that this interface is in the businessRules package.
(Programmer :) okay. So what is Something used?
(Senior Architect) It represents a simple business object. I put it in another bag named entities.
Public class Something {
Public void makeChanges (){
//...
}
}
(Senior Architect: At last, you need to implement the BusinessRuleGateway interface. This implementation class will know the relevant database details:
Public class MySqlBusinessRuleGateway implements BusinessRuleGateway {
Public Something getSomething (String id ){
// Read some data from MySQL
}
Public void startTransaction (){
// Start a transaction
}
Public void saveSomething (Something thing ){
// Save the data to MySQL
}
Public void endTransaction (){
// End the transaction
}
}
(Senior Architect) you can see that the business logic calls the database at runtime. During compilation, the database package references the businessRules package.
(Programmer :) okay, I think I understand. You use polymorphism to hide the database implementation. However, the database tool interface is still referenced in the business logic.
(Senior Architect: No, not like this. We did not intend to provide all the database tool interfaces for the business logic, but created the interfaces required by the business logic. You can call corresponding tools when implementing these interfaces.
(Programmer :) well, if the business logic requires all the tools, you must put all the tools into the Gateway interface.
(Senior Architect :) ha, I don't think you understand.
(Programmer :) do not understand anything? I think it is clear.
(Senior Architect) each business logic only defines the interfaces it requires.
(Programmer :) and so on. What do you mean?
(Senior Architect) This is called the interface separation principle. Each business logic only uses a part of database tools, so each business logic only defines interfaces that meet the needs.
(Programmer :) in this way, you will have many interfaces and many implementation classes.
(Senior Architect :) ha, yes. You begin to understand.
(Programmer :) this is a waste of time! Why should I do this?
(Senior Architect) This is done to make the code clean and save time.
(Programmer :) Forget it. This will only add more code.
(Senior Architect :) On the contrary, this is actually a very important architectural decision, which is different from the so-called important decisions you mentioned earlier.
(Programmer :) what do you mean?
(Senior Architect :) Do you remember saying you want to become a software architect at the beginning? Do you want to make all the important decisions?
(Programmer :) yes, I thought so.
(Senior Architect: You want to make all decisions about databases, Web services, and frameworks.
(Programmer :) yes, but you say they are not important. They are also irrelevant to important decisions.
(Senior Architect: Yes, they are indeed irrelevant to important decisions. All the important decisions that a software architect must make are beyond the database, Web server, and framework.
(Programmer :) But first, you must decide what database, Web server, or framework to use!
(Senior Architect: In fact, you should do these things in the later stages of development-after you have mastered more information.
(Senior Architect: When the architect hastily decided to use a database, he later found that using a file system is more efficient.
(Senior Architect: When the architect makes a hasty decision to use a Web server, he finds that what the team needs is just a socket excuse.
(Senior Architect: When the architect hastily decided to use a framework, he found that the functions provided by the framework were not required by the team, but brought many constraints to the team.
(Senior Architect: The architect determines the database, Web server, or framework to use only when he has enough information.
(Senior Architect: when architects identify IO devices and frameworks that are slow and resource-consuming for the team, they can build a fast-running lightweight testing environment.
(Senior Architect) when the architect focuses on those truly important things and puts those unimportant things aside.
(Programmer :) I have no idea what you are talking about.
(Senior Architect :) well, if you haven't switched to management in a few years, you may understand all this ......

Document Source: public document