10

A Data Structure is any structure that holds data. Data Structures are distinguished from each other by their memory usage and performance characteristics. For example, the lookup performance of a Hash Table is O(1), while that of a balanced binary tree is O(log n). A Collection is any data structure that can hold zero or more data items. Generally, ...


10

You need to understand that DDD is not about primary keys, rows or tables - these are just means to implement it. Aggregate root is usually implemented as a class, because you are expected to access all the functionality and data of the aggregate through the root. It therefore needs to have some behavior, something which primary key of the table can't have. ...


10

Your option 2 is usually preferred. Option 1 violates the common guideline known as the "Law of Demeter" -- it means that your main program now knows in detail how your Recipe voting works, which makes it harder to change that if you decide to do it another way later. This is an example of unnecessary coupling, which we usually try to minimise.


8

Decision that what should be selected as an aggregate root is highly dependent on business rules of your application . If for example , there are two entities say A and B are highly dependent i.e. some operations on entity B requires change in entitiy A then A and B should be under same aggregate root . In short if consistency is needed between two ...


7

They don't. Those concepts reduce or centralize the number of calls your business code needs to load any data objects by calling CRUD code directly, but actually the CRUD code to load or update or save the objects still has to be somewhere, since it is used, at least, from inside the repository. You reduce the need of writing such boilerplate by using code ...


7

In the DDD perspective, Category, Product and Property are entities: they all correspond to objects that have their own identity. Option 1: your original design You made Category the root of a single aggregate. On one side, this makes sense, because the aggregate shall ensure consistency when its objects are modified, and Product must have the ...


6

The database layer certainly shouldn't be involved- it should be UTC and UTC only, unless there's some special logic about timezones involved instead of just converting the times. In an ideal world, if the client wants to display data in non-UTC, it should perform the conversion there, as this is more of a display/rendering detail. However, if for some ...


6

Problem A) Yes, that's fine. RESTful POSTs are permitted to generate side effects on other resources. I'd suggest breaking out messages from conversations in your URI hierarchy in this case, or allowing clients to POST a message resource to /conversations to create a new conversation. It could respond with a Conversation Message with a "self" URI pointing to ...


6

You need a process manager/saga that do exactly what you need without using transaction that spawn multiple aggregates. Basically that Saga would reserve the ticket right before the payment begins and would markTicketAsSold after the payment is successful or releaseTheReservation after the payment is failed. This process and the invariant that a reserved ...


6

If you want to do it the right way as DDD suggests, then you are only allowed to change shape colour by using a method on the aggregate root directly and you cannot do it on the shape directly. The aggregate root is only allowed to expose its internal entities as read-only objects (e.g. exposing internal collections as IEnumerable). However, good aggregate ...


5

First of all, DDD is really about creating a model where reading the code is like how the actual domain experts would be talking about the domain. Second, they way DDD describes an aggregate root, the child objects on the aggregate root are merely properties on the aggregate root itself, and you shouldn't be able to access the child elements directly, only ...


5

Could Vote, in this case be considered an "aggregate" and be deserving of its own repository and aggregate status? I think this might be the right answer. An aggregate should be a transactional consistency boundary. Is there a consistency requirement between votes on a match? The presents of a Vote collection on a Match aggregate would suggest that there ...


5

For terminology in Domain Driven Design, start from "the blue book" -- Domain Driven Design by Eric Evans. AGGREGATE A cluster of associated objects that are treated as a unit for the purpose of data changes. External references are restricted to one member of the aggregate, designated as the root. A set of consistency rules applies within the ...


5

it's kind of weird that I can have two repositories Get used to it. It's long been considered good practice to model your use cases explicitly. From the perspective of the application, it has a reference to a repository that plays the role of providing a reference to a particular flavor of aggregate root. So you might have interface Product { // ... ...


5

As I see it, you can solve this in one of two ways: Category is a special type of product This means for any given product in your database, it contains a foreign key pointing to the very same table product. A product is a product only if there exist no products whose foreign key is equal to the id of said product. In other words, if it has no products ...


5

Repository is set up to get ARs by their ID from the event store. That should suffice. If you need to query a collection of ARs from the repository you should use a specially designed Read model. Put it another way, you are using CQRS. This means that you cannot query the Aggregate to check it's product code and it's natural that you cannot query the ...


5

aggregates consume commands and produce events: What is the foundation for this rule? In DDD, the Aggregates are the only one that are allowed to mutate the system state, so they are the only one that receive and execute commands and produce the state mutations. This is because they need to enforce the business rules. The state mutations are then returned ...


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 ...


4

There is no "database" or "transaction" in DDD. DDD is completely agnostic to databases, transactions or "eventual consistency". So any definition that includes those is not valid for DDD. That basically leaves only your fist definition. Which I feel is the correct one. Also, I don't see how you can feel Martin Fowler's description fits anything else than ...


4

Not all data is required for every bounded context While a Contract might indeed have a large number of fields, not every field will be relevant for every bounded context. For example, if you have an Invoice for a Customer that was created as part of a Contract it is very likely that there is information for the Contract that is not relevant for invoicing. ...


4

I think the answer to what you are trying to achieve is how to identify bounded contexts. An aggregate on its own can indeed by thought of as a consistency boundary for all entities and value objects enclosed with in. However, you don't expose your entities directly to the outside world. To apply DDD effectively start by identifying your sub-domains. Find ...


4

This events will be fetched by AR2 and then processed. Ohh, that sounds like a bad idea. One more notice - in AR2 this layer would be read-only = needed to do some business logic inside AR2. So looking at your picture, AR2 is writing out events (d,e,f), which says that AR2 is not read only -- which is good; read only aggregate roots don't make sense. ...


4

UserAggregate user = mUsersRepository.getUser(userId); At this point I become confused. Yeah, that's a bit of a tangle. However, if multiple UserAggregate objects will be used simultaneously, these objects might get out of sync with each other (while staying consistent individually). I get a feeling that having several "non-synchronized" instances of ...


4

But I heard that this is not quite good practice to inject services to aggregate root via method arguments or DI, but maybe it's OK? There are trade offs. Evans describes domain services as a construct to serve this role. So we pass to the aggregate an adapter that expresses the gateway concept in the domain language, so that the model can interact with ...


4

Lots of questions, but some things are clear Your Inspector can't contain Inspections. These only increase with time, so sooner or later there will be too many to load into memory. You need to move them to an aggregate root which fits with how you are going to use them. Perhaps Batch? Presumably you will fail a batch if a certain proportion of Inspections ...


4

Lets start with a quote form Evans in his DDD reference book: Sometimes services masquerade as model objects, appearing as objects with no meaning beyond doing some operation. Keeping this in mind, we can now look at the DDD definitions: AGGREGATE: A cluster of associated objects that are treated as a unit for the purpose of data changes. ...


4

A good starting point for you would be Yves Reynhout's Evolving a Model, where he describes the modeling of appointment scheduling for healthcare. You might also want to review Greg Young's discussion of warehouse systems. The summary is this: if you have a reasonable way to detect and report a scheduling conflict in your data, you may not necessarily need ...


3

Your domain model contains your business logic in its purest form. All the relationships and operations that support business operations. What you're missing from your conceptual map is the idea of the Application Service Layer the service layer wraps around the domain model and provides a simplified view of the business domain (a projection if you will) ...


3

I think you want to go for a design of normalization within one Bounded Context. If one aggregate is a pure subset of the other (e.g. the product for cart is a subset of the product for product) I'd probably use a single table. Otherwise, I'd probably use a second table that refers to the first table rather than duplicating columns between two tables. For ...


3

If Employee is an aggregate root, it means that all the outside objects can reference only the Employee (and not the ActiveEmployee/InactiveEmployee). Any references from outside the aggregate should only go to the aggregate root. DDD aggregate by Martin Fowler I don't think that's your intent. I think ActiveEmployee and InactiveEmployee are both ...


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