4

Contrary to what the article says, it is actually considered best practice to reference other aggregates by ID, and exactly to solve the kind of issue you are facing (having to load a bunch of related entities to construct the root object, which then leads to performance issues). There's an excellent series of articles by Vaughn Vernon that talks about this ...


3

From your question, it is clear that the functionalities belong in separate bounded contexts. So the straightforward answer would be No, you shouldn't. It is good to assume that someday in the future, given sufficient scale and performance requirements, each bounded context will become a Microservice of its own. So if you want to use some functionality in ...


3

The TL;DR is: yes, there are technical challenges in preventing collisions, but it's really something you should ask your business department. Best practice from a business perspective isn't a sequential number, but one that contains some structure. If the structure is chosen well, it may help avoid most race conditions. One example is to use timestamps ...


3

Q: Should we fetch the Engine and Model from the database by their ids before building the domain model ? Yes, this's what repositories do. If Car is an aggregate, the repository should be capable of fetching whatever Car needs for its initialization. It might load Engine and Model directly from the data store or ask for them to other components. You also ...


2

There will always be some level of dependency in any system which is unavoidable. In the case of the LoyaltyService, imagine it existing with no dependencies to CustomerService. Conceptually then, you can have loyalty without having a customer, which doesn't make sense. So the dependency on the CustomerCreatedEvent is perfectly acceptable. The details of ...


2

If both projects use .NET, nothing prevents you from having a common library which would define the base classes. In a case where you cannot or don't want to have a common project, such as when two services use a different technical stack (say one is in Haskell, another one uses PHP), you can: Either duplicate the class, Or create the class automatically ...


2

different order of receiving the commands produce different aggregate root states. Yes, in general How can I check domain rules based on the state when the order of commands are not guaranteed? How to check if a command can be executed based on the last state of the aggregate root if the command is sent by an asynchronous message queue like Rabbitmq? ...


1

Loosely coupling is the key for re-use. Create/Define an exchange format (preferably something open and established like XML Schema or use JSON) and send serialised messages to your messaging sub-system. Now you are open to read and process the message in all interested receivers (eg: your loyalty service). Use your messaging system to route the messages ...


1

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


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

It's normal to have multiple "aggregates" that are interested in the same correlation identifier. Mauro Servienti has a talk that discusses how a "monolithic" aggregate might break down into smaller, more focused elements. If you were doing this with event sourcing, the correlation-identifier that binds the different aggregates together would probably ...


1

I would lean towards Approach 1, with one modification. EmailService does not need to know the concept of a User. Two points to further clarify: By forcing EmailService to know about the concept of User, you are potentially opening yourself to the high-effort task of keeping the service in sync with potential changes across different bounded contexts. ...


1

Neither approach achieves a suitable level of decoupling. As you correctly point out in your first sentence, an EmailService should be given the responsibility of abstracting the formatting and transfer of an email (collectively known as "email logic"). As such, an EmailService should be concerned with information about emails (headers, body, etc), not users!...


1

You're dealing with a symmetric relation. There are a number of ways for modeling symmetric relationships, and here's a third approach for you adapted from here. CREATE TABLE people ( person_id int IDENTITY(1,1) PRIMARY KEY, ...other columns... ) CREATE TABLE matches ( match_id int IDENTITY(1,1) PRIMARY KEY, ...other columns, if any... ...


1

I am going to propose a mechanism from the Functional Domain modeling world. And I am going to offer an example usecase, although it would have been easier if you had given a concrete example. I apologize in advance for putting the code in Python if you are not familiar with the language, but in my defense, it almost looks like pseudo-code :) Assumptions: ...


1

One of the primary rules to keep in mind while designing aggregates is that Aggregates are intended to define consistency and transactional boundaries. Within their boundary, all invariants of the aggregate are satisfied ALL the time. To elaborate on the terms, an invariant is simply a business rule that must always be consistent. The consistency here ...


1

I want to strongly discourage directly using DB id's as user readable identifiers of any kind. Every unique identifier should only be beholden to one system. If you publish your DB id's where users see them they'll find some reason to mess with your system. Steve Jobs famously insisted on a having a different employee id number when he learned he was number ...


1

I know this question is from some years ago, but I've been dealing with a similar modelling problem at the moment, and perhaps it will be useful to someone else to see what alternative opinions are out there. You're right, this section is a bit misleading and contradictory, as so much time is spent in DDD indicating that the domain design shouldn't be ...


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