From the view of architecture of software

Overview

This year, I read books about the foreign Daniel and the ancestors, and recently I have been working on the project structure myself. See some peer talk, some feelings

There are also areas of disapproval, and here is a discussion of your own architectural view.

1. Architecture is not for playing technology

Many people are playing technical skills, but the architecture is not a show, but some people are doing it,

Architecture Audit Standards First: convenient, easy to maintain, suitable for the need to constantly adjust business scenarios.

Once in a business has seen such a scene: so-called a leader 10 years of time to lead a bunch of people to do a simple information management system,

All of them were in a mess, but they played the tech show-learning to be a ddd person.

The consequences of managernent--completely in the form of imitation, the system as the need to adjust and boosts immediately become out of the body.

There is also a clear manifestation: the flexibility of development and maintenance is completely lost.

Architecture is not a performance, but a service to the needs and developers.

With async await friends, you'll probably find problems with Microsoft Design: Consistency issues, UI programming patterns (WinForm WPF, and so on) and

Implementation conformance issues in pure programming mode. This not only reminds me of the always-spurned ASP. NET WebForm, Microsoft has done some ridiculous things (until Vnext's appearance) over the years.

Microsoft has not been able to do that for years-that's not what I said, but a former Microsoft Asia Architect. Don't ask me who I am, I won't tell you.

Because these people are playing the technical concept, not the good architecture.

2. The purpose of the architecture is to simplify the software engineering refinement

The best scholars in the world can always speak the truth to the layman, rather than complicate the simple problem . --The beauty of mathematics.

As far as DDD is concerned, I agree with the hierarchy of ideas, but the use of people is estimated to be managernent,

I asked: Do you use DDD so completely in the form of a set? or let all the business are waiting for you to use??

Some people agree with my rhetorical question, others agree with each other. Various reasons are not commented.

Let's just think of one thing: the only constant in software development is that business needs are changing: adjusting, adding or subtracting.

The purpose of the architecture is to serve the needs and developers.

3. Inspection Structure Ultimate Postgraduate Examination--current market

These years out of a few browser-based PC operating systems, such as Google, Hewlett-Packard and so on?? There are similar mobile phone operating systems such as Mozilla.

The architecture concept is perfect, but eventually it becomes the edge, the obsolete thing.

First and foremost, their design concept is perfect, in terms of architecture:

Using HTML5

1. Solve the development cost problem;

2. Addressing the scarcity of developers;

3. Solve the maintenance problem of the operating system itself;

The above is their wishful thinking, but they finally failed, they say the reason for failure---performance and user experience.

But think about it, didn't they think about it at first? No, never make such a low-level mistake,

Regardless of how this problem is considered, at least they think that performance should not be a problem at the time.

So why did it fail?

They are out of the test of the current market: the products in the market, their strengths themselves,

After all, the rest of the system has become a market Big Mac, and its new things have the basic conditions to subvert the current demand???

This is the consequence of the disconnect between it decision makers and the market.

4. How the architecture is measured in code

Code re-usability, coupling, maintainability, testability

Before talking about these four features, let's talk about business functions,

All development revolves around the business function, and each business function (e.g. recharge) is

Other smaller functions that revolve around the business.

The more responsibility, the more difficult to re-reuse;

The more involved, the more likely it is to be coupled;

The input and output can be easily constructed and observed for better testability.

5. Seek to move

No one told you when to develop agile, when it should be waterfall-type development,

However, no matter what kind of development and development model, it is essential to seek

To make a move is not to refer to a development model, but a principle of doing things.

Come out to mix sooner or later are to also, sensible understand this truth.

------------------------------------------

6. Vision determines success or failure

Did you know about this?

From the view of architecture of software