domain-driven-design 相关问题

域驱动设计（DDD）是一种通过将实现与核心业务概念的演进模型深度连接来开发满足复杂需求的软件的方法。请注意，最好在softwareengineering.stackexchange.com上询问概念性DDD问题。

我和我的大学正在讨论领域驱动设计背景下的价值对象和实体。这有点理论化，所以可能不太容易回答。第一个问题：可以

entity domain-driven-design aggregateroot value-objects

回答 1 投票 0

在这个问题中https://softwareengineering.stackexchange.com/questions/396151/which-layer-do-ddd-repositories-belong-to?newreg=f257b90b65e94f9ead5df5096267ef9a，我知道我们应该避免说话...

domain-driven-design

回答 1 投票 0

Laravel 中的 DDD 和 MVC

我完全困惑了。 Laravel结构是MVC，但是最近听说有时开发者在laravel中使用DDD。那有什么意义呢？有在 MVC 中使用 DDD 的示例吗？我试图找到一些 Lar...

laravel model-view-controller domain-driven-design

回答 1 投票 0

如何在干净架构中更新相关实体

我的问题是关于更新与聚合根相关的实体。我有一个 Shipping 类，我的命令是 SetShipmentAsDelivered。 Shipment 与 Order 类有关系。所以当

domain-driven-design clean-architecture aggregateroot

回答 1 投票 0

域实体中的外键属性

在领域驱动设计中，领域模型应该完全不知道任何数据持久细节。假设一名员工属于一个部门。域实体可能看起来...

c# entity-framework domain-driven-design repository-pattern poco

回答 2 投票 0

域事件处理程序和数据库更改事件

我是域驱动和 CQRS 的新手，对事件处理程序机制有点困惑。 Domian 事件正在触发发生的事件。例如创建的帐户。公开课账户：AggregateRoot...

design-patterns domain-driven-design cqrs

回答 3 投票 0

避免对 Hibernate / Spring JPA 的原始痴迷

在我们的 Spring Boot 3 (Kotlin) 项目中，我们应用领域驱动设计，并希望避免对实体和存储库（尤其是 ID，通常是 GUID 类型，并且很容易被修改）的原始痴迷。

spring-boot kotlin spring-data-jpa domain-driven-design

回答 1 投票 0

领域、基础设施和应用层一致性的固有问题

我陷入困境。我正在开发一个强大的系统，它被分成多个微服务。我目前正在开发的是一种简单的实时聊天。然而，我认为自己无所作为 -

domain-driven-design

回答 1 投票 0

DDD：从其他子域获取实体的正确方法？

我们有订购和发票子域。我们需要访问订单才能创建发票。从发票应用程序服务访问订单的正确方法是什么？拥有进销存申请服务...

go domain-driven-design ddd-service applicationservice

回答 1 投票 0

如何使用购物车产品对象构建购物车

我是 DDD 新手，在构建对象时遇到困难。我有一个购物车，我可以在其中添加产品。每个产品都有一些属性，如图像、标题、价格等。每当产品...

object oop domain-driven-design

回答 1 投票 0

努力成为一名更好的 Flutter 程序员

有人可以告诉我通过事先订阅调用 Riverpod 提供者的方法有什么好处吗？使用不带回调的监听，如下所示？： @riverpod 未来或有人可以告诉我通过事先订阅调用 Riverpod 提供者的方法有什么好处吗？使用不带回调的监听，就像这样？: @riverpod FutureOr<Option<User>> signInState(SignInStateRef ref) { final sub = ref.listen(authStateProvider.notifier, (prev, next) {}); ref.listenSelf((previous, next) { next.whenData( (user) { if (user is Some<User>) { sub.read().authenticateUser(user.value); } }, ); }); 不直接做，如下： @riverpod FutureOr<Option<User>> signInState(SignInStateRef ref) { ref.listenSelf((previous, next) { next.whenData( (user) { if (user is Some<User>) { ref.read(authStateProvider.notifier).authenticateUser(user.value); } }, ); }); 我已经在项目的各个部分看到过这样做，但我不明白为什么它是一个更好的选择。我怀疑这背后有一个宝贵的学习机会。谢谢你。我尝试通过调试收集更多信息，但没有找到任何相关信息。我收到了代码所有者的回复。我分享它是希望它可以帮助那些想在我们的职业中脱颖而出的人：从技术上来说，authStateProvider 是否 keepAlive 没有什么区别。但是，确保听取提供商的意见是一个很好的做法使用 ref.read 进行变异时（如果提供者没有其他侦听器在树里）。请参阅以下示例： @riverpod class Bar extends _$Bar { @override int build() => 0; void increase(int i) { state = state + i; } } @riverpod Future<int> Foo(FooRef ref) { final sub = ref.listen(barProvider.notifier, (prev, next) {}); ref.listenSelf((previous, next) { next.whenData( (state) { sub.read().increase(1); }, ); }); } 如果 barProvider 树中没有监听器并且您直接使用 ref.read，行为会有所不同，因为 barProvider 将是每次 ref.read 调用都会立即调用并处理。以下是我从回复中得到的要点： With providers marked as keepAlive like authStateProvider: 无论您直接使用 ref.listen + sub.read() 还是直接使用 ref.read() 都没有多大关系。在任何情况下都不会不必要地重建提供者。性能或优化没有显着差异。 On the other hand, with providers not marked as keepAlive: 如果直接使用 ref.read()，则每次调用都会重建提供程序。相反，使用 ref.listen + sub.read()，仅重建一次。这可以提高未标记为 keepAlive 的提供商的性能。如果您对此主题有更多评论，欢迎留言！问候。

flutter dart domain-driven-design clean-architecture

回答 1 投票 0

如何在存储库中的域模型上设置私有字段

我目前正在使用使用贫血域模型的代码库，并且我正在尝试将更多逻辑移至域模型中，以迈向域模型和域驱动设计，但我...

c# asp.net domain-driven-design

回答 3 投票 0

无符号数而不是检查 DDD 中的不变性

如果您知道数字不能为负数，那么在 DDD 模型中哪种设计更好？公共记录数量（uint Number）；公共记录数量() { 公共 int 数字 { 获取;在里面; } 公共Qu...

domain-driven-design

回答 1 投票 0

EF Core 非原始类型值对象作为主键？

我一直在尝试使用值对象作为实体框架核心中的唯一ID。我已经正确保存到数据库了，但是 EF 没有正确查询数据库...