5

Just because you have a many to many relationship at a data or database level, doesn't mean it has to be represented in code. You should model for the relationships you care about or are useful to you. The relationship of roles to users is more of an implementation detail and not something worth modelling at all at a code level, let the database handle the ...


3

whether I should store this data within the domain or just consider the historical metrics to be a query model and use CQRS to persist it separately? One thing to keep in mind is that your domain model is not the authority for your vehicle metrics -- the real world is. The real world is a firehose of telemetry pointing at you. So typically that data is ...


3

I think a lot of the confusion here is a result of focusing on data instead of behavior. The purpose of DDD is to model the functional requirements of a system to provide a useful abstract of your business domain. This means that we model according to behavior and let the data that supports our behavior become an implementation detail. So let's start there! ...


2

While it's difficult to surmise exactly what an "ideal" solution would look like without a more comprehensive understanding of your system and its goals, I'm going to argue for none of the above. You may have ruled out the simplest option (the one that creates the least amount of interleaving) without giving it enough consideration. Keeping a single Task ...


2

Creation patterns are weird Notice that, in this use case, you are changing two things; the Task aggregate itself, and also your collection/repository/stream of TaskLogEvents. Twenty years ago, when "the" database meant some RDBMS, both of these would be written as part of the same database transaction. It would be the responsibility of the application ...


2

This is about how you (the developer, or a team of developers) decide to model the problem (i.e., how you decide to view and represent various elements involved based on your understanding of the problem and the relationships within). That means that the same example can be under different circumstances modeled in two different ways (e.g. in a racing game, ...


2

Aggregation is defined by UML as a „property that has a shared semantic“ (section 9.5.3): Indicates that the property has shared aggregation semantics. Precise semantics of shared aggregation varies by application area and modeller. This is rather vague: It is generally understood as a part/whole relation, with parts that can potentially be shared. ...


2

Composition means mine! Keep your hands off. Aggregation means look what showed up here. Association means look what I can find. Let's try giving these examples some actual stories. If a car is composed of tires it means those tires belong to that car and nothing else. No sticking them on bicycles. When the car gets crushed in the junk yard the tires are ...


2

Some times an aggregation with no members makes sense... Imagine that one of the classes on your system represents a movie. And you want the system to keep the Actor credited in the movie. Does a movie without actors make sense? Yes. It could be some silent animation or other artsy stuff that manages to have no actors. I find that a better text book example ...


2

To your question: "Does the usage of these references between the classes on the same aggregation root hurt the aggregate pattern principle from domain driven design?". No. This is the intention of aggregate. One of the entity should be able to refer other entity in the same aggregate. When you are doing DDD, aggregates are transactional boundary. And when ...


2

Well, it depends on where you draw the "boundaries" of your Domain and how flexible you want to be with respect to serving various use cases. In any case, the fact that the objects share their lifetimes does not necessarily mean they are better aggregated together. It looks like your CustomerSettings object is not really a Domain-related entity, in the ...


1

The UniversityOfInterest aggregate must contain the business rules for determining ResidencyType. Given that determining ResidencyType requires information from two different aggregates (Student and University), this responsibility doesn't really fit into UniversityOfInterest and would be better modeled in a domain service. UniversityOfInterest should be ...


1

Short answer: try modeling the number's customer instead of the customer's number. A big part of domain modeling is digging into the domain language to discover entities that might not be obvious. TelephoneNumber is probably an entity in your domain - it's a thing that has a life cycle. You acquire the rights to it from your supplier, you assign those ...


1

In this stuation, User is an aggregate root. Roles are part of user. But If I want to use Many-to-many relations with Role and User, how changes the aggregation? In this stuation which is the aggregate root? Aggregates don't share entities. Which means, if "Role" is a thing that changes over time, then each instance of role will belong to one and only one ...


1

First things first imagine we have an Aggregate Root TaxesDetail which OrderItem has a reference to it, ... First, take a deep breadth in. What makes you think that a TaxesDetail could be an aggregate root in the first place ? And what would be the aggregate ? If only the OrderItem could create the TaxesDetail then TaxesDetail will simply be a ...


1

Maybe you need to step back and take a different look at this. Don't try to be too dogmatic about DDD, and whatever you've read on the Internet about aggregate design, take it with a grain of salt. First, this is how you store data - this is not necessarily exactly representative of your domain concepts; your database structure doesn't have to exactly map to ...


1

In the same aggregation root, there are Car and Computer I think this is where you are going wrong. In your example Computer is the Aggregate Root. You can only have one 'root' object per aggregate. If you think of things this way around your object graph just becomes a standard parent-child tree where you need to load all the objects in order to keep ...


1

Your reasoning on creating the TaskLog as a separate aggregate is correct and makes sense. The responsibility of raising an event lies with the business logic, so prima facie, Option 1 would be the best choice. You would come close to this code structure if you follow DDD anyway, with a Task Application Service, Task Aggregate, and a Task Repository. But ...


1

Note: specifically relating to delete, you may want to review Don't Delete -- Just Don't. But where does CatalogEntries go ? If I delete a catalog I need to delete all it's entries but if I delete a product I need to delete all entries from this product too. An important element is time: do you need to delete all of the catalog entries that refer to the ...


1

I'm a little confused about That's not your fault. The literature sucks. What people are really talking about is the way that information flows around our "domain model". Commands carry new information toward our domain model "Domain Events" describe changes to the state of the model "External events" carry information away from the model. The first and ...


1

The problem with this approach is that there is a limit to the amount of memory a computer can have and no limit to the number of orders a customer can make. You will "probably" be ok with the low level of orders, but in 5 years time why will you want to load 20 previous orders, with potentially all their related delivery and payment info, every time you ...


1

In DDD Agreegate Root objects or ARs are supposed to group together all the data that is significant to the calculations you need to make in your business logic. So in your order and items example. If you need to calculate the shipping cost of an order by adding up the weight of each item then you should have Order.Items which contains all the items in an ...


1

Adding to the existing comments and answers, I would also suggest that you can use interfaces to abstract semantically equivalent concepts from different concrete types. For example, you may have DepositCash and WithdrawCash commands, both of which implement IJournalEntryCommand, and then have a single command processor called createJournalEntry which takes ...


1

Personally, I do think that the main goal of DDD is to make code communicate the same language as domain experts do thus easing the mental burden of mapping actual business domain to your code. That's why I think that having both DepositCash and WithdrawCash is better as it more closely resembles the language of domain experts. Regarding the notion of DRY ...


1

Your use case entirely depends on the demands from your business analytics. If an invoice without a single line makes no sense and must not exist, creating an empty invoice should not be possible within your code either and creating an invoice should always require a line (or lines). If an invoice might be created without specifying lines and the lines ...


1

But my question is performance. Just to add a comment to a sub-task we are loading en entire aggregate root into memory. How can this be efficient? It isn't. Don't do that. This is not a question of DDD. The design of your abstractions and logical model do not dictate the implementation. If you think that DDD requires that you load everything into ...


1

Leaky Abstractions and Abstraction Bypasses When the abstraction breaks, and bypassing it feels prefferable, its time to fix the abstraction. Find a cheap way to speed it up, and put off actually fixing it. Adjust the abstraction to provide an optimised redline path for that specific operation. Fix the abstraction generically Dismantle it entirely and ...


1

Can Aggregate shared between services? The short answer is: no. To ensure consistency, you normally want only a single authoritative representation of an aggregate. That will normally mean that the aggregate is "stored" in one place - for example, in "the database". So in a way, sharing the authority for an aggregate is analogous to sharing a database ...


Only top voted, non community-wiki answers of a minimum length are eligible