dddd

How to manage two coupled aggregates in DDD?

由 十年热恋 提交于 2021-02-11 14:09:23
问题 I am developing Electric Vehicle Charging Station Management System, which is connected to several Charging Station s, and I am in an impasse. In this domain, I've come up with an aggregate for the Charging Station , which includes the internal state of the Charging Station (whether it is connected, the internal state of its Connectors). It has a UnlockConnector method, for which, to accurately respect its name(and not be anemic) it sends the request to the respective Charging Station , as it

How entities covered with in an aggregate Root are saved in DDD?

由 别说谁变了你拦得住时间么 提交于 2020-03-25 18:54:13
问题 After reading lot of posts, I realised if an aggregate root exists for a concept/context, we need to have a single repository for that whole concept/context. If thats the case, I see there won't be any repositories for the internal entities. If so, how these internal entities are saved to database? I have a many internal entities under the aggregate root. So, wondering If I need to have all the saving of the internal entities under the aggregate root repository, it's going to be bloated.

Implementing set-based constraints in CQRS

由 泪湿孤枕 提交于 2019-12-20 10:13:16
问题 I'm still struggling with what must be basic (and resolved) issues related to CQRS style architecture: How do we implement business rules that rely on a set of Aggregate Roots? Take, as an example, a booking application. It may enable you to book tickets for a concert, seats for a movie or a table at a restaurant. In all cases, there's only going to be a limited number of 'items' for sale. Let's imagine that the event or place is very popular. When sales open for a new event or time slot,

DDD using STE vs POCO

由 旧时模样 提交于 2019-12-20 06:39:02
问题 Developing n-layered application with DDD (o better DDDD because we are using WCF) using Microsoft technology (where we have full controll of all component), the best choise seems to be STE vs POCO (this last one force the usage of DTOs). That's right? In your opinion make sense the usage of STE with DTOs where we need them? Thanks. 回答1: I really can recommend Julie Lerman's Programming Entity Framework. She goes in depth about simple poco's, dto's and Self Tracking Entities. Advantages and

Akka.Net VS MS Orleans Comparison [closed]

由 半世苍凉 提交于 2019-12-03 08:08:07
问题 Closed . This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this post. Closed 3 years ago . I've started implementing several LOB application with CQRS/ES and for this evaluating: several EMS: NServiceBus, MassTransit, RhinoMessageBus Akka.net + DDDD MS Orleans + DDDD There are lot of comparisons of different EMSs but no evaluations of Actor Frameworks. So, could you

Alternatives to many-to-many relationships with CQRS

由 久未见 提交于 2019-12-03 00:53:36
问题 How do we model classic many-to-many relationships with CQRS/DDD? I know that both DDD and CQRS implementations and solutions tend to be domain-specific, so it may be difficult to come up with a general answer to this question. However, let's assume we have the familiar relationship between Book and Author . This is a classic many-to-many relationship. To me, it seems most natural that Book and Author are two different Entities that each belong in their own Aggregate Root . Thus, explicitly

Akka.Net VS MS Orleans Comparison [closed]

由 家住魔仙堡 提交于 2019-12-02 21:40:40
Closed . This question needs to be more focused. It is not currently accepting answers. Learn more . Want to improve this question? Update the question so it focuses on one problem only by editing this post . I've started implementing several LOB application with CQRS/ES and for this evaluating: several EMS: NServiceBus, MassTransit, RhinoMessageBus Akka.net + DDDD MS Orleans + DDDD There are lot of comparisons of different EMSs but no evaluations of Actor Frameworks. So, could you please compare Akka vs Orleans, namely: features presents conciseness of syntax (Akka is line-by-line porting

Alternatives to many-to-many relationships with CQRS

由 爱⌒轻易说出口 提交于 2019-12-02 14:17:49
How do we model classic many-to-many relationships with CQRS/DDD? I know that both DDD and CQRS implementations and solutions tend to be domain-specific, so it may be difficult to come up with a general answer to this question. However, let's assume we have the familiar relationship between Book and Author . This is a classic many-to-many relationship. To me, it seems most natural that Book and Author are two different Entities that each belong in their own Aggregate Root . Thus, explicitly modeling the many-to-many relationship between them is not the way to go. How do we model an

DDD using STE vs POCO

由 烈酒焚心 提交于 2019-12-02 10:57:42
Developing n-layered application with DDD (o better DDDD because we are using WCF) using Microsoft technology (where we have full controll of all component), the best choise seems to be STE vs POCO (this last one force the usage of DTOs). That's right? In your opinion make sense the usage of STE with DTOs where we need them? Thanks. I really can recommend Julie Lerman's Programming Entity Framework . She goes in depth about simple poco's, dto's and Self Tracking Entities. Advantages and disadvantages are described. But off course depending a lot on application requirements and personal taste.

Using Kafka as a (CQRS) Eventstore. Good idea?

由 眉间皱痕 提交于 2019-11-26 16:52:16
Although I've come across Kafka before, I just recently realized Kafka may perhaps be used as (the basis of) a CQRS , eventstore . One of the main points that Kafka supports: Event capturing / storing, all HA of course. Pub / sub architecture Ability to replay the eventlog which allows the ability for new subscribers to register with the system after the fact. Admittedly I'm not 100% versed into CQRS / Event sourcing but this seems pretty close to what an eventstore should be. Funny thing is: I really can't find that much about Kafka being used as an eventstore, so perhaps I must be missing
订阅 dddd