Shulou(Shulou.com)06/03 Report--

If you see my article for the second time, welcome to scan the code at the end of the article to subscribe to my personal official account (cross-border architect).

It will be delivered to the official account at 8 o'clock every Friday morning. Of course, I will add a meal from time to time.

In a distributed system development team, there are some problems that can easily lead to conflicts among programmers.

One of them is "business attribution", that is, when you add / modify a business, should the code changes be placed in your system or mine?

It goes without saying that the outline of some business is very clear, and everyone's recognition is the same. For example, those related to goods are put into commodity services, and those related to members are put into member services.

But for businesses with vague outlines, people may not make the same decisions.

What matters at this time is not your respective work experience, but whether your "business thinking" is global and how well you know the overall business.

Once the "inappropriate" attribution is made hastily, it will bring a lot of additional costs, such as collaboration, higher bug rate and so on.

See if you have seen the following scenes?

Hey, xxx, I have a bug that I need you to debug with me.

If only this business had been here at first, but now it is not easy to solve the long-term accumulation, so we can only do it again.

I think this problem may be caused here or there.

Therefore, which project a business belongs to seems to be a very simple multiple-choice question. But the default choice in everyone's mind is different, such as the following two completely different tendencies.

The only thing I can solve is for me to solve it, and give it to the other party if I can't.

Only what I can solve here is solved by me, and all the others will be solved by the other party.

In fact, these choices vary from person to person, and it is difficult to form a consensus that is universally applicable.

If both sides choose the second point, it is inevitable to have conflicts and disputes.

Even if the first thing everyone chooses to be "think of others" is to avoid wrangling with each other, it still can't avoid the extra cost of subsequent business boundary chaos.

Therefore, we still need to extract the essence from it as a criterion for decision-making.

Brother Z, I think that when thinking about business ownership, it is essentially impossible to escape the scope of "high cohesion and low coupling". A reasonable project attribution will make the software system one step closer to the "high cohesion and low coupling" expected by everyone.

Because "business attribution" is the same as "high cohesion and low coupling", they are all "drawing lines" and defining boundaries.

But most of the time, we don't know exactly where the "line" should be drawn, we just know an approximate direction.

In fact, if our system is only a single application, there is no problem of "business ownership".

Therefore, it is a side effect caused by the division of labor and cooperation.

However, as long as we continue to maintain the division of labor and cooperation to develop a distributed system, this problem is an inevitable hurdle.

In the work, due to the unclear boundaries, it is easy to cause business ownership differences in the following two scenarios.

A new business needs to be completed by both sides.

An old business is handled partly by An and partly by B.

Pause here for a minute and think about it. If it were you, how would you make a choice?

Brother Z, my advice to you is that you can think about it this way: which side without this business will lead to the failure of at least one process.

Let's give two examples to help you understand.

An e-commerce website is now going online with a membership card function, similar to the 88 members of Ali.

The effect is that users who buy this membership card will enjoy a 20% discount when purchasing self-operated goods on this platform.

So why don't you think about it? Is this business put into "member service" or "promotion service"?

To think with reference to the above advice is to answer two questions:

Membership service lacks this membership card business, is there at least one process that can not work?

The promotion service lacks this membership card business, is there at least one process that can not work?

Obviously, although the membership card has a discount function, but this discount is based on an identity.

Then it is necessary to consider whether this identity will be displayed or corresponding exclusive business in multiple links throughout the shopping link, such as exclusive customer service, monthly benefits, and so on.

In addition, you will find that if the promotion wants to achieve a 20% discount, it can be done without the existence of a membership card.

Therefore, the nature of this membership card is more like an extension of membership attributes, following a specific member.

If eventually accidentally attributed to the promotion service, then each business around the membership card needs to be coupled with the promotion service to be completed, obviously deviating from the original intention of "high cohesion and low coupling".

Therefore, for promotional services, membership card business is not essential. Relatively speaking, the membership service is more closely related to it.

At this point, the answer to the first example comes out and should be put into the member service.

Let's look at the second example.

With the rise of the social e-commerce model, the e-commerce platform wants to have a group buying function.

So this function should be included in the "shopping cart service"? Or in the "promotional service"?

Also answer two questions:

Shopping cart service lacks this group buying business, is there at least one process that can't work?

The promotion service lacks this group purchase business, is there at least one process that can not work?

First of all, what we can easily think of is that group purchases generally place orders directly, without going through the shopping cart, naturally do not need to put into the shopping cart service, it is appropriate to put it into the promotion service.

This understanding is perfectly reasonable. But can we think about it again, does group buying have to be put into the promotion service?

In fact, group buying is just a mouthful price, and there is no need to calculate the price of promotion.

From this point of view, group buying is not a "rigid demand" for sales promotion.

At this time, it is a better choice to make the group purchase service independent. Because in this case, the lack of group buying business will not cause a process hindrance to both services.

On the contrary, after it becomes independent, it will be easier to adjust the group purchase business. There is no need to have any impact on shopping cart services and promotional services.

At this point, I believe you already have a sense of how to determine the project ownership of a business. If you want to implement "high cohesion and low coupling" as the design policy of the system, you might as well learn "domain-driven design".

This is the concept put forward by Eric Evans, which regards modeling as, demarcating system boundaries, and so on as the highest priority development mode.

I believe that as the future business becomes more and more complex, the software design concept based on business as a starting point will become more and more valuable.

Because technology is only one of the media to achieve business, and the emergence of new technologies is getting faster and faster.

So, instead of using the best new technology, choose the most appropriate technology for the business.

All right, let's sum up.

This time, Brother Z helped you analyze the reasons behind the differences in "business ownership".

Then, a suggestion to think about the problem correctly is shared, and two examples are given.

In the future, if you are not sure which project the business should belong to. Just remember one sentence: where the business is missing, at least one process will fail. If it all works, then this new business is suitable for an "independent portal".

In the daily work of programmers, there are many problems that are prone to disagreement, but in fact, most of the problems have a general solution-global business thinking.

Recommended reading:

The focus of distributed system-the "seed of destruction" behind caching

8-month polishing, a collection of "distributed systems" for programmers

Author: Zachary

Source: https://www.cnblogs.com/Zachary-Fan/p/businessattribution.html

If you like this article, you can click "recommendation" in the lower left corner.

This will give me some feedback. :)

Thank you for your help.

▶ about the author: Zhang Fan (Zachary, personal WeChat account: Zachary-ZF). Persist in polishing each article with high quality and originality. Welcome to scan the QR code below.

Publish the original content regularly: architecture design, distributed system, product, operation, some thinking.

If you are a junior programmer, you want to promote but don't know how to do it. Or as a programmer for many years, I fell into some bottlenecks and wanted to broaden my horizons. Welcome to follow my official account "Cross-border architect", reply to "Technology" and send you a mind map that I have collected and sorted out for a long time.

If you are an operator, there is nothing you can do in the face of a changing market. Or you may want to understand the mainstream operation strategy in order to enrich your "warehouse". Welcome to follow my official account "Cross-border architect", reply to "Operation" and send you a mind map that I have collected and sorted out for a long time.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.