Java生鮮電子商取引プラットフォーム-マイクロサービス生鮮電子商取引ユーザーセンターのシステム設計(小プログラム/APP)
6930 ワード
Java生鮮電子商取引プラットフォーム-マイクロサービス生鮮電子商取引ユーザーセンターのシステム設計(小プログラム/APP)
説明:マイクロサービス生鮮電子商取引ユーザーセンターのシステム設計の中で、私はずっと1つの観点を強調して、あなたのこのシステムがユーザーを使うのはいったいTO Bですか、それともTO Cですか.これは肝心です.
しかし、多くの人が答えています.私は業者が入居し、Bエンドのユーザーが購入し、Cエンドのユーザーの購入もサポートしたいと思っています.この話は間違いなく、誰もが自分のプラットフォームがN中のビジネス形態をサポートすることを望んでいます.
しかし、私の長年の生鮮電子商取引の生涯によって、私は発見して、実はB端とC端のユーザーはすべて異なる業務形態で、必ず強制的に柔らかくして一緒にいてもいいことを発見して、ただシステムを複雑にすることができます.
では、具体的にどのようなビジネスシーンが一致しないのでしょうか.
1. 出荷先住所
2. 支払い方法
3. 決済方式
4. 価格体系
5. ソフトウェアの使用
説明:
1. 出荷先の面では、Bエンドユーザーにとって、出荷先と受取人はある意味で相対的に固定されており、ほとんど変化していないが、Cエンドユーザーは非常に異なり、極めて変化しやすい.
2. 支払いの方式の方面から、B端のユーザーにとって、多くの时歩いたのは帐期の支払いで、私达のよく言う押帐で、これは今の市场の非常に普遍的な1种のモードです.しかも領収書が必要です.
しかし、Cエンドのユーザーにとって、ほとんどが支付宝と微信であり、直接注文して支払う.
3. 決済方式については、Bエンドのユーザーにとって、帳簿に対する需要があります.つまり、取引ごとに取引明細が必要です.また、帳簿に対する需要から、支払いに至るまで、領収書に至るまで、長い道のりがあります.
お金が手に入らないだけだ.
4. 価格体系の面では、Bエンドのユーザーにとって、異なる顧客が同じ商品で、彼の価格は違いますが、Cエンドにとって、価格体系はほとんど同じです.
5. ソフトウェアの使用については、Bエンドのユーザーにとって、BエンドはAPPが好きで、Cエンドのユーザーは小さなプログラムが好きです.
このような業務形態は一致しないが,互換性を持たなければならない方式であり,現在はコードの複雑さを増す以外に,マイクロサービス分割を採用しても現在の業務形態をうまく処理することは困難である.
では、どのようにしてマイクロサービスアーキテクチャの設計を行いますか?(データベースレベル)
Cエンドユーザー
Bエンドユーザー
2.コードとアーキテクチャはどのように作成されますか?
説明:ユーザーセンターの業務設計は無視できない技術問題であり、実戦の中で向上する必要があり、自分の業務によって自分で調整することができ、生搬硬套を覚えておくことができる.
3複盤と総括.
まとめ:
インターネットの応用をして、生鮮の小さいプログラムに関わらず、APPに関わらず、目的はユーザーを残して活性化するためで、ユーザーの購買力を形成して、満足度を高めて、最終的に取引を達成して、もちろん本文はただレンガを投げて玉を引いて、本文がみんなに少し思考と提案を与えることができることを望みます.
私はシステムを分けて研究開発することを提案して、同時に異なる取引先に対して異なるアーキテクチャの設計があって、最終的に統一的な注文アーキテクチャ、物流配送アーキテクチャなどに達します
QQ:137071249
共同学習QQ群:79330535
説明:マイクロサービス生鮮電子商取引ユーザーセンターのシステム設計の中で、私はずっと1つの観点を強調して、あなたのこのシステムがユーザーを使うのはいったいTO Bですか、それともTO Cですか.これは肝心です.
しかし、多くの人が答えています.私は業者が入居し、Bエンドのユーザーが購入し、Cエンドのユーザーの購入もサポートしたいと思っています.この話は間違いなく、誰もが自分のプラットフォームがN中のビジネス形態をサポートすることを望んでいます.
しかし、私の長年の生鮮電子商取引の生涯によって、私は発見して、実はB端とC端のユーザーはすべて異なる業務形態で、必ず強制的に柔らかくして一緒にいてもいいことを発見して、ただシステムを複雑にすることができます.
では、具体的にどのようなビジネスシーンが一致しないのでしょうか.
1. 出荷先住所
2. 支払い方法
3. 決済方式
4. 価格体系
5. ソフトウェアの使用
説明:
1. 出荷先の面では、Bエンドユーザーにとって、出荷先と受取人はある意味で相対的に固定されており、ほとんど変化していないが、Cエンドユーザーは非常に異なり、極めて変化しやすい.
2. 支払いの方式の方面から、B端のユーザーにとって、多くの时歩いたのは帐期の支払いで、私达のよく言う押帐で、これは今の市场の非常に普遍的な1种のモードです.しかも領収書が必要です.
しかし、Cエンドのユーザーにとって、ほとんどが支付宝と微信であり、直接注文して支払う.
3. 決済方式については、Bエンドのユーザーにとって、帳簿に対する需要があります.つまり、取引ごとに取引明細が必要です.また、帳簿に対する需要から、支払いに至るまで、領収書に至るまで、長い道のりがあります.
お金が手に入らないだけだ.
4. 価格体系の面では、Bエンドのユーザーにとって、異なる顧客が同じ商品で、彼の価格は違いますが、Cエンドにとって、価格体系はほとんど同じです.
5. ソフトウェアの使用については、Bエンドのユーザーにとって、BエンドはAPPが好きで、Cエンドのユーザーは小さなプログラムが好きです.
このような業務形態は一致しないが,互換性を持たなければならない方式であり,現在はコードの複雑さを増す以外に,マイクロサービス分割を採用しても現在の業務形態をうまく処理することは困難である.
では、どのようにしてマイクロサービスアーキテクチャの設計を行いますか?(データベースレベル)
Cエンドユーザー
CREATE TABLE `user` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`username` varchar(63) NOT NULL COMMENT ' ',
`password` varchar(63) NOT NULL DEFAULT '' COMMENT ' ',
`gender` tinyint(3) NOT NULL DEFAULT '0' COMMENT ' ：0 ， 1 ， 1 ',
`birthday` date DEFAULT NULL COMMENT ' ',
`last_login_time` datetime DEFAULT NULL COMMENT ' ',
`last_login_ip` varchar(63) NOT NULL DEFAULT '' COMMENT ' IP ',
`user_level` tinyint(3) DEFAULT '0' COMMENT '0 ，1 VIP ，2 VIP ',
`nickname` varchar(63) NOT NULL DEFAULT '' COMMENT ' ',
`mobile` varchar(20) NOT NULL DEFAULT '' COMMENT ' ',
`avatar` varchar(255) NOT NULL DEFAULT '' COMMENT ' ',
`weixin_openid` varchar(63) NOT NULL DEFAULT '' COMMENT ' openid',
`session_key` varchar(100) NOT NULL DEFAULT '' COMMENT ' KEY',
`status` tinyint(3) NOT NULL DEFAULT '0' COMMENT '0 , 1 , 2 ',
`add_time` datetime DEFAULT NULL COMMENT ' ',
`update_time` datetime DEFAULT NULL COMMENT ' ',
`deleted` tinyint(1) DEFAULT '0' COMMENT ' ',
`balance_money` decimal(12,2) DEFAULT '0.00' COMMENT ' ',
`user_integration` int(11) DEFAULT '0' COMMENT ' ',
PRIMARY KEY (`id`),
UNIQUE KEY `user_name` (`username`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COMMENT=' ';Bエンドユーザー
CREATE TABLE `buyer` (
`buyer_id` bigint(20) NOT NULL DEFAULT '0' COMMENT ' user ID',
`buyer_name` varchar(64) DEFAULT NULL COMMENT ' ( )',
`buyer_address` varchar(256) DEFAULT NULL COMMENT ' ',
`lng` varchar(32) DEFAULT NULL COMMENT ' ',
`lat` varchar(32) DEFAULT NULL COMMENT ' ',
`province_id` int(11) DEFAULT NULL COMMENT ' ',
`city_id` int(11) DEFAULT NULL COMMENT ' ',
`region_id` int(11) DEFAULT NULL COMMENT ' ',
`boss_name` varchar(32) DEFAULT NULL COMMENT ' ',
`boss_tel` varchar(16) DEFAULT NULL COMMENT ' ',
`balance_money` decimal(12,2) DEFAULT '0.00' COMMENT ' ',
`buyer_level` tinyint(4) DEFAULT NULL COMMENT ' ，1 A ,2 B ,3 C ',
`buyer_type` int(4) DEFAULT NULL COMMENT ' ，1 ，2 ，3 ，4, ',
`sale_id` bigint(20) DEFAULT NULL COMMENT ' id',
`remark` varchar(256) DEFAULT NULL COMMENT ' ',
`buyer_logo` varchar(126) DEFAULT NULL COMMENT ' logo ',
`buyer_images` varchar(1024) DEFAULT NULL COMMENT ' ， ',
`open_time` varchar(20) DEFAULT NULL COMMENT ' ， ',
`end_time` varchar(20) DEFAULT NULL COMMENT ' ',
`delivery_time` varchar(20) DEFAULT NULL COMMENT ' ',
`delivery_area_id` bigint(20) DEFAULT NULL,
`buyer_menu` varchar(128) DEFAULT NULL COMMENT ' ',
PRIMARY KEY (`buyer_id`),
KEY `index_sale_id` (`sale_id`),
KEY `index_region_id` (`region_id`),
KEY `index_delivery_id` (`delivery_area_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;2.コードとアーキテクチャはどのように作成されますか?
説明:ユーザーセンターの業務設計は無視できない技術問題であり、実戦の中で向上する必要があり、自分の業務によって自分で調整することができ、生搬硬套を覚えておくことができる.
3複盤と総括.
まとめ:
インターネットの応用をして、生鮮の小さいプログラムに関わらず、APPに関わらず、目的はユーザーを残して活性化するためで、ユーザーの購買力を形成して、満足度を高めて、最終的に取引を達成して、もちろん本文はただレンガを投げて玉を引いて、本文がみんなに少し思考と提案を与えることができることを望みます.
私はシステムを分けて研究開発することを提案して、同時に異なる取引先に対して異なるアーキテクチャの設計があって、最終的に統一的な注文アーキテクチャ、物流配送アーキテクチャなどに達します
QQ:137071249
共同学習QQ群:79330535