Why is all martial arts?-Let's talk about the core position of the business domain.

The business domain is the core value of the software.

Enemies or friends: project managers and architects
From repository to domain
From MVC to testing
From automated testing to domain
Code factory = crud?

Enemies or friends: project managers and architects

Whether it is a software product or a development project, the customer invests in the Business Value of the software. The project manager is directly responsible for this goal and produces software products with high business value at minimal cost and as short as possible. Architects span a single project and are responsible for this goal for a long time.

Project managers and architects are born enemies. In the short term, they are right. In the long term, they are real friends and strategic friends. A project without a Project Manager will die very quickly; but without an architect, the company will die very badly.

I am still easy to understand the roles and actions of the Project Manager. 1. He is short-lived and short-sighted, so the role of the project manager is close to human intuition. 2. The activities of the Project Manager are also common and often said, there are many examples and stories. We have many misunderstandings about architects, at least vague.

 

I have asked many developers about your five-year plan? Almost all of them wanted to be an architect. Especially for students at school, they almost blurted out. This is an interesting phenomenon. My understanding is: 1. His career is in the technical aspect. To make some achievements in technology, architects are an obvious technical benchmark. From this perspective, i'm sure they answered. 2. This theory has been deeply rooted in the hearts of the people and good for the software industry, with two lines of light project management and architects. 3. Architects have become synonymous with "development difficulties.

 

The architect is not a guy who only cares about the "architecture", but also a master. Various technologies, whether elegant or vulgar, are a weapon in his pocket. Are there any vulgar technologies? Yes, a lot of new-entry developers feel outdated.

What, inherit, are you old? You can only say that the design mode does not dare to say that you are doing development. Currently, all clouds are clouds. Nooooosql has a strong reputation when it comes to this name. A negative error is correct. There is no defect in this world. Therefore, our slogan is to deny everything! Okay, it's too far.

Yes, the architect's toolbox should contain a wide array of amazing tools. However, this is only a view of the architecture. We often stare at these tools too tightly. See how the tool or technology itself is dazzling and cool. Today, let's look at the goal of tools and technologies from another perspective. Who is it?

From repository to domain

First, repository ).Repository is not Dal!Although they are so close, some architectural designs combine them into one. Repository is used for Object persistence, and Dal is used to operate data from the database. Still confused. Can't you see the difference between the two?

Let's come to a thinking game:

1. The three-tier architecture is used to explain the benefits of the Dal layer, and database changes are used as an example. For example, the system used orcal databases before, and now it needs to be replaced with SQL Server. If we use the Dal layer, we can easily implement it without touching the rest of the system.
2. I want you to consider another change, from storing data in a database to using a file system, such as CVS or XML file to put data (if you want to be more advanced, it's cooler, you can think about using cloud storage ). At this time, the isolation of the Dal layer can no longer be solved. Instead, we need to go to the upper layer, which is our repository.

Therefore, repository and Dal are two layers. Naturally, this increases complexity and you really need to determine whether your system is necessary. In addition, nhibory can play the Dal role well, and supports repository well. Proper application can reduce the workload.

Return to the repository description. The repository is used to persist the objects in the business domain. Careful people can find that I have added three words "business domain".

From MVC to testing

Secondly, MVC.MVC is not a three-tier architecture. Although it seems to be divided into three parts, it is definitely not. In addition,M in MVC is not a business domain,No. Although some system implementations adopt this method and merge the MVC m with the business domain object, they are completely different in principle. It is a little interesting for Microsoft to replace m with a VM (view model.

The biggest purpose and function of MVC is to isolate the things related to the final interface (V Part) to the maximum extent, because this part cannot be tested, and those are still related to the interface, contains a large number of logic (algorithms ?) In C or M. Makes the boundary of tested code as much as possible to the forefront of the UI. Although many automated UI testing tools are available, the functions are good, but compared with unit testing and code direct interface testing, the efficiency and quality are still different.

Still go back to thinking about the purpose. Why is MVC? To test? I am afraid it is not the ultimate goal. What is the purpose of the test?

From automated testing to domain

Unit Testing, behavior testing, integration testing, and many terms, I don't want to discuss the differences between them. As a type of concept, they only show half of the meaning in terms of name. Another important part is missing "Automation ". Automated unit testing and automated integration testing are more accurate. Naturally, here I will not discuss non-automated testing, such as functional testing and acceptance testing.

The benefits of automated testing are self-evident. The test mentioned in MVC in the previous article is to improve the coverage rate of automated testing. For the entire system, it is impossible to reach 100% coverage. On this premise, we can easily ignore the importance of improving the coverage rate of automated testing. What is the difference between 90% and 70% in numbers? Let me take it closer and split the system. The entire system cannot reach 100%. What is the problem? The view mentioned above is one, and the database is one. It is not completely impossible to test. The theory is acceptable. It is actually troublesome and not worth it. There are some external functions, such as sending emails and reading and writing files. File operations seem to be the most frequently used functional blocks of unit tests. After all these exclusion rules, let's look back. We can say that the remaining 100% tests must also be tested. Otherwise, they are about the architecture and design.

Most of the remaining 100% are business domain models, which are of the highest priority, difficult, and value.

Code factory = crud?

The previous responsitory and MVC seem complicated and simple, but the logic is fixed. Yesterday, I spent an hour adding a simple class. The actual functions are from the front-end controller (MY NAME IS command) to the service layer, service class, And respository and database, it took only one hour. Because the logic is simple and fixed, it is equivalent to the crud of a table. Many of the so-called one-stop solution frameworks are typical cases of this situation, especially Microsoft, from VB to the current Entity Framework, the coolest demonstration is to add several lines of data definition in one minute, from the interface to the background. Of course, this is much faster than my manual work yesterday. However, back to actual commercial software development, we have never been able to complete a project in one day based on such efficiency. Isn't it? If one-minute interface or a data table, a project with 100 tables is large enough? In this way, we can simply perform multiplication in less than 100 minutes? Actually, 100 minutes is not enough, that is, 100 hours. Therefore, such a demonstration has no meaning at all, but many people are happy with it.

In my previous company, there was an architect who completed a so-called framework based on ibatis and created data tables to automatically generate business objects and crud code. Then I proudly announce that 80% of the development work has been completed. However, the project was developed for another two years. If it is 80% of the Code volume, I can say that it is 80% of the workload? I doubt.

This is exactly the fact that many of our architects are not aware of or are unwilling to admit. The framework has been designed and the architecture has been set up. This is just the beginning, not the end.

This is the end of an adventure in the business field.

 

In the next article, we may come up with a classic example in the business field: year, month, and period ). Interested?