3

If domain experts use different terms consistently, there is a chance that there might be a subtle difference between two closely related concepts. Your narrative suggests that your two applications could be in two different bounded contexts. Each should have its DDD model that uses the term of the relevant domain experts. Hypothetical example: one expert ...


3

No, don’t reuse aggregate root keys for identifying different objects in different contexts ! Why? Because a Notificant is not a User. Maybe today, mostly users get notified. But tomorrow you may have to notify third parties who are not using the system, or even automatic monitoring systems. Because it’s another bounded context, and bounded contexts may ...


2

It seems you are overthinking this. The advice is illustrated in a few different and related use cases. 1. User Submits Proposal: Use case where the user is responsible for ensuring Proposal is consistent. In other words, it is considered the user's responsibility to cause a consistent outcome of data mutation. (A) User defines a Proposal and submits it to ...


2

Connection Strings, Paths, and URIs. A Connection string is a string containing all the information needed to connect to a service. A good example of this are ODBC connection strings. They identify the specific kind of service provider which further processes the string to connect to its service. A Path is a string which directs a given service to a ...


1

Although a composite key is not a bad practice, I would recommend you to use a UUID. Lets consider an UUID v4, for example, that is generated randomly: The number of random version-4 UUIDs which need to be generated in order to have a 50% probability of at least one collision is 2.71 quintillion [...] Source: Universally Unique Identifier - Collisions So, ...


1

First and foremost, the main idea of having a domain model is to wrap your business logic. Second, an aggregate is a set of business-related entities (order and orderline can form an aggregate), each aggregate should have a root, which is logically the one entity that forms transactional consistency boundary, so for example if you delete it you'd delete all ...


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