My view of software architecture

In the traditional enterprise application development, the project often adopts "chimney type" development model, data processing, business logic and interface operation melted miscellaneous together, quickly launch a usable version, this is understandable.

But with the development of enterprise applications and the advancement of mobile Internet, you will find that your system can not easily connect to other factory systems, and can not quickly develop other platform applications. Faced with this problem, we have to consider the changes in the architecture. And all of this is predictable or can be planned ahead of schedule.

Problems with traditional architectures

Traditional enterprise Development architecture has many shortcomings in the face of change:

1. Many modules have to be re-built wheels

2. Coupling over-depth between modules

3. Problems that are difficult to trace

4. The testability is poor

5. Data and services between systems cannot be shared

This will inevitably lead to more redundancy and more difficult maintenance as the project becomes more accountable.

Schema partitioning

In my opinion, the development of enterprise software should be divided into two pieces of service and terminal.

Desktop applications, Web programs, and ios,android programs can be considered as terminals, and as a terminal my task is to show the data, to initiate commands/requests, and not to care about how much of the business logic and data processing it has, all I want is data.

And as a service, I don't care how you layout the interface, I just need to respond to your request to give you the data on the line.

Such a structure I think can let the foreground and background work together (who said the desktop program can not be sub-background), and because the unified business logic can be applied to multiple terminals.

Scalability

Service orientation is a decoupled process, and loose coupling reduces the dependency between services. In large projects, in order to guarantee large concurrency and high availability, we typically make a cluster of service groups or split the services into multiple parts and deploy them separately.

Cluster-deployed mode with load-balanced service availability and performance per server (shown as simple architecture diagram, master-slave mode, and distributed database schema)

With service splitting, the service is split across multiple servers to achieve a "distributed" effect. For the web App picture is the most resource-intensive, so we need to separate the image and page, which is basically the strategy of large-scale web site, they have a separate or even multiple image server. Such a architecture can reduce the pressure on the server system that provides page access requests.

Cache mode

The use of data caching in software engineering is a very meaningful strategy, not only to reduce the database load, and when the data is cached in memory, can greatly improve the reading speed.

You can add a memory cache to your service or put your data in a 3-party high-performance cache (Memcached,radis, etc.).

And as a cache you have to focus on several aspects:

1. What is the key for this data cache?

2. How long is this data cache life cycle?

3. How to access your cache in an external service

4. Landing strategy for cached data

5. Distributed cache master-slave backup

And so on, the specific cache strategy needs you to combine the project consideration, the personal comparison recommendation Memcached, enough on the line.

WCF,WCF Restful,webservice,webapi?

For. NET system, these technologies are able to decouple resources and services, and which technology needs to depend on your application scenario.

Personally, I prefer to use the WCF TCP pattern for enterprise intranet applications, which is highly efficient and supports duplex communication.

When it comes to docking web and mobile applications, it's a priority to recommend WEBAPI and standardize the HTTP protocol. I used WCF rest to do mobile apps, and after experiencing the Web API I felt that WCF was too heavy and webapi handy.

Summarize

Chimney-style development architecture I think that when developing a project prototype or a small project, you have to think about the overall project development architecture whenever it is possible to involve Web applications and mobile applications or if there is a big concurrency.

The above is a summary of some of the personal experience of their own projects, the understanding of the less profound place to welcome everyone to point out.

My view of software architecture