8000 一些问题 · Issue #40 · totoro-o/hixtrip · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

一些问题 #40

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
hrghluug opened this issue Apr 11, 2024 · 12 comments
Open

一些问题 #40

hrghluug opened this issue Apr 11, 2024 · 12 comments

Comments

@hrghluug
Copy link
  1. DDD 不仅是一个架构，也可以是一个划分领域（微服务）的方法论，而微服务对应到单体项目中应该是一个模块，而不是这样水平切分。
  2. 基础设施层依赖领域层？高层依赖底层？
  3. 库存业务中，不应该存在直接修改，数量应该是通过新增和减少来操作。库存预扣和库存占用对实际业务操作没有区别，为了统计生出来的概念。为什么会有预扣库存的业务？
@hrghluug
Copy link
Author

基础设施层依赖领域层？低层依赖高层？

@AirNessNN
Copy link

回复您的问题：

1. 微服务与单体项目中的模块划分：
DDD作为一种设计方法论，确实能够指导我们有效地划分业务领域，进而设计出合理的微服务架构。而在单体应用程序中，这种划分思路同样适用，只不过体现为内部不同的模块结构。尽管如此，在单体项目中，这些模块不是物理隔离的服务，而是逻辑上的分离，它们仍然共存在同一个部署单元中。当应用DDD时，我们会尽量避免直接的水平切分，而是依据业务领域内的上下文边界来组织模块，使其尽可能地独立且可复用。

2. 基础设施层与领域层的依赖关系：
在DDD架构中，依赖关系遵循自上而下的调用链，即高层组件（如应用层或用户界面层）依赖于领域层的服务和实体，而领域层则不应该直接依赖基础设施层。相反，基础设施层提供了通用的技术实现，例如数据库访问、消息队列接口等，它是领域层执行业务逻辑所需的外部资源。领域层通过依赖注入或者其他形式的抽象接口间接使用基础设施服务，保证领域模型不受具体技术实现的约束。

3. 库存业务操作及其背后的业务需求：
在库存管理业务中，遵循业务规则，库存的数量不应该被随意直接修改，而是应当通过明确的库存增加和减少操作来更新。这是因为直接修改库存可能会导致业务逻辑混乱和数据一致性问题。预扣库存这一概念的确立，主要是出于对某些特定业务场景的支持，例如在电商中，当用户下单时，为了防止超卖现象发生，需要预先锁定一部分库存，这就是所谓的“预扣”。虽然预扣库存与实际占用库存从最终库存量变化上看可能并无实质差别，但在业务流程中，它们分别代表着不同的状态和意图——预扣库存用于表示待确认的库存消耗，而库存占用通常意味着交易已经达成或者准备就绪，正在等待物流等后续环节。这种区分有助于更好地支持复杂的业务流程和实时库存统计分析。

@hrghluug
Copy link
Author

我是同意第二点的，但是这个项目中使用水平切分才出现的，底层依赖高层

@hrghluug
Copy link
Author

第三点中的 我可以理解成预扣库存是为了实时统计才有的吗，是为了避免统计未支付的订单而造成的效率低吗

@hrghluug
Copy link
Author

你这里也提及了库存不能直接设置，那这个方法的作用是什么
image

@liyovoyil
Copy link

回复您的问题：
关于您的疑问刚刚我们应该已经回答的很详细了，建议您参考下相关DDD的文献。
至于第三点，请细看我们给出的解释。

@hrghluug
Copy link
Author

你要不要看一下你的项目是不是水平切分的？
关于第三点，根据未支付（待确认）的订单 来查有什么问题？

@AirNessNN
Copy link
  1. 我们所理解的“水平切分”概念可能不是同一个，我们认为微服务设计层面的水平切分在此上下文中并不适用，请先给出您对于项目进行水平切分的定义；
  2. 之前聊到的预扣库存的意义，不仅仅体现在实时统计中，也体现在一个意义明确的业务中，大多数电商行业模型中都引入了库存预扣来解决订单履约和库存变更中存在的一些问题；在题目中的设计要求，我们并没有约束您必须使用何种库存模型，以上代码截图中四个参数已有足够的设计灵活度，您只需补充其实现、完成调用逻辑即可；
  3. 对于您提到的_“根据未支付（待确认）的订单 来查有什么问题”_这个问题缺少一些关键因素，导致我们无法准确理解您的想法，请给出完整的上下文；

@hrghluug
Copy link
Author

概念似乎有点对不上。
1.水平切分按照架构层次划分。(当前项目采用的)
2.垂直切分按照业务领域划分。
3.可售库存未被下单占用的。
4.预占库存已下单未支付的。
5.占用库存已下单且支付成功的。
6.库存预扣下单后(无论是否支付)减少redis库存。
这是我对这个项目概念的理解，有问题可以指出。
基于我的这些理解
1.库存预扣我完成了，当被告知未实现。
2.我上图提到的方法，不应该有这个业务来操作这些库存。
3.为了保持基础设施层的可扩展性，单独划分一个模块可以理解。但是其他层采用垂直切分更优。
希望您可以直接指出这些问题的错误？

@hrghluug
Copy link
Author

关于未支付订单这个问题，是我混淆了预扣库存和预占库存

@AirNessNN
Copy link

关于层次划分的回答：

首先，架构层面的层次划分在这个项目中不存在问题；其实DDD 分层架构也是基于传统的分层架构设计而来，在 DDD 中，更加强调业务领域是软件的核心，因此通过依赖倒置与依赖注入形式为领域层提供了一个干净整洁不受具体技术约束的环境；

其次，在本题中，使用一个领域描述一个简单的标准电商业务的下单功能也并无不妥。

DDD作为一种设计方法论，确实能够指导我们有效地划分业务领域，进而设计出合理的微服务架构；但是，在我们描述 DDD 领域业务时，也尽可能聚焦与业务本身，而不是引入其外在的技术（例如您说的微服务或单体的架构设计）；

关于操作库存的业务合理性的回答：

用 DDD 的思想来对业务进行领域建模，我们大致能得到一个基本的下单聚合根，下单时对库存进行相关扣除本就属于业务领域的一部分，因此并无不妥；建议使用事件风暴对领域建模后再做分析。

如无其他问题，我们就 close 这个 issue 了

@loyayz
Copy link
loyayz commented Apr 14, 2024

你们这个分层方式跟阿里的那个COLA一致的，以前我也在公司内推过，但并不是个人都很能理解DDD，大都数人不太能接受这种分层方式，我们主推的几人得耗费大量的精力来code review ，收益并不高。
另外提个建议，你们在工程中定义了多个领域服务类，并在要求中不允许新增接口。理论上当你为每个包定义了领域服务，说明他们逻辑上就不属于同一个领域，因此并不能构建一个聚合根来使用他们，而应该往上提一层，即在应用服务来使用他们。如果你们是想考察面试人对DDD的理解的话，我觉得现在已定义的类和要求是不合适的。至少我个人是没找到聚合根和值对象的定义方式。

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@loyayz @AirNessNN @hrghluug @liyovoyil
0