Some thoughts on business

I haven't written a blog about thinking for a long time , There are exactly three business-related content to talk about . They are combination goods 、DDD、 Handover , Separately and model 、 framework 、 Adjustment correlation .

A combination of goods

Combination of goods on food 、 Cosmetic GMV Promotion is of great help .

Definition

First, clarify the definition of combined goods ：

Noun	explain
A combination of goods	A commodity composed of multiple sub commodities or a commodity type composed of multiple sub commodities
Sub commodity	Common goods on the platform , The product selected when publishing the combined product , Will be defined as a sub commodity
Combined selling price	The single product is in the process of releasing the combined product , Set the selling price of the item , Different from the price of goods sold separately

For example, shampoo and hair cream can be combined into a commodity for sale .

technical design

When I first made composite products , Trading decisions do not perceive sub commodities , Only perceive the main commodity , Sub product information is only transmitted through . The advantage of this scheme is that the transaction only needs to focus on the main logic , Don't pay attention to details .

But the goods will eventually be split into sub goods , Then send it to the user , This part of the task is handled by the performance .

Deduce

As the business grows , We find that this design will bring many problems ：

1. If you need to dynamically add some attributes when placing an order for a sub product , Transactions do not perceive sub commodities , It can't be achieved

2. A premise that transactions do not perceive sub commodities is , Other departments get transaction snapshots , Only the main commodities are needed , No sub items are required . Once you need to perceive sub commodities , Each group needs to disassemble itself , Virtually increase costs

in summary ：

1. What model to adopt , We must do a good job in deduction , It is necessary to predict whether the current model can meet future business needs

• Experience here is extremely important

• Adopt a certain scheme , We must not take the convenience of development as the criterion . Because the cost of later changes is much higher than that of doing it at one time

2. Personally think that , If you are the starting point for dealing with a problem and the central department that each group depends on , It's best to cover these differences

3. If a new function node leads to a new model , This is a particularly good opportunity , We must design a new model , And integrate with existing models

DDD

explain

DDD These two years have been very hot , But it has not been fully promoted . I have read two books before DDD The book of , Domain Driven Design lite and Domain Driven Design ： The corresponding way of software core complexity . I suggest using DDD, Because as the business becomes more and more complex , It is difficult to cope with rapidly changing businesses using traditional models . but DDD The cost of learning is very high , We need to practice constantly 、 To feel . If you have a chance , Try your best .

It can be understood from two aspects DDD, One is from the system design , One is from the concept .

• In terms of system design , Build all fields , And continue to refactor

• In concept , You need to understand what your core domain is , Dare to make choices

example

The reason to talk about this topic , Because I found that the Department A Yes DDD Have a deep understanding of . It's also a little funny , and A Combine to make a big project , The technical scheme has been decided , But there are changes before development .

There was little change , We are the caller , Originally A The group will provide many packaged interfaces , Not available now , Only provide basic capabilities , namely RPC Interface ,API The interface of layer requires us to develop independently .

I understand the reason for this choice , because A Group

1. The number of developers does not match the number of businesses supported , Too many people live too few

2. Business is changing fast , It is difficult to sort out common content in the application layer , If not handled well, the problem will be further aggravated 1

So they choose to focus on model construction , Make sure the model is available 、 Extensible , As for the upper business , Who uses who assembles .

The benefits are clear , One is to be able to achieve convergence , Strength is spent on the blade , Not disturbed by mundane things ; Second, you can have more time to exercise your internal skills , Solve technical debt , Assign a new tone to the team ; Third, members can grow in a higher dimension .

The disadvantage is that the business group needs to develop more by itself , Different businesses may have the possibility of repeated development , But the impact is generally good , Because it also means providing more autonomy for business parties , Development efficiency may not be low .

I appreciate A The way the team solves the problem ： Set the tone 、 Ensure the implementation of （ tough ）. These two steps are not easy , Setting the tone means finding the core point of solving the problem , Although this tone is not quite consistent with the previous scope of responsibility of the team . Ensuring implementation requires persistence and courage , Fortunately, it's the brother team , Everyone can understand and support each other .

But I feel as I practice my internal skills , Finally, we have to move up to the application layer , Converge to a general business model , Only in this way can the influence be further expanded .

Handover

A few months ago, due to the organizational structure adjustment , Some projects have been handed over . I support handover , Because a reasonable handover can help the business develop faster , On the whole , Everyone can benefit .

For very specific projects , Direct handover . But there are some businesses , In the middle , What is the basis for judging whether handover is required ？

Up to now, I still don't fully understand what the standard is , However, some projects have been done in the middle , There are some corresponding thoughts ：

1. Where will the demand come from ？

• If it comes entirely from other teams , It's better to hand over directly . Any product has a long-term plan , Production and research are not in the same team, It will be very winding

• If most of the requirements come from the corresponding product team , Then it should not be handed over

• If the demand may come from the corresponding product team , It may also come from other teams , You can ask what the product plans for this module , If there is a detailed plan , Don't hand over

2. What is the value of the project ？ Is the project consistent with the main channel ？

• This requires your own value for the project 、 Have a deep understanding of the main channel in the future . Whether it's individuals or teams , Energy is limited , You need to focus on the most valuable things

• If the value is low 、 Inconsistent with the main channel , It's best to hand over

3. Whether it can improve efficiency

• Complete functional modules , If you can hand over everything, you can hand over everything . Such as performing the order , Need to push orders to service providers 、 Receive the notice of each order node from the service provider . If this function needs to be handed over, it should be handed over together , Because it's not good to divide into two parts , There may be out of order problems 、 If there is a problem with the system, both sides should check 、 The whole process data monitoring also needs to obtain data from different locations , It can't bring efficiency improvement

Handover is still a test of the depth of business understanding . Of course, if some modules are not well thought out , Don't hand it over first , According to the subsequent demand , Gradually know how to choose a more appropriate , It's OK to deal with it after you figure it out .

Last

If you like my article , You can pay attention to my official account. （ Hot programmer ）

My personal blog is ：https://shidawuhen.github.io/

Review of previous articles ：

0. Design patterns

1. Recruitment

2. reflection

3. Storage

4. Algorithm series

5. Reading notes

6. Gadget

7. framework

8. The Internet

9. Go Language