Stack Exchange Network

Stack Exchange network consists of 175 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.

Visit Stack Exchange

New answers tagged

0

I'm just learning DDD and a question raised in my mind about unique identifiers in an entity. Identity, especially identity of real world objects, is much more subtly difficult than the DDD literature suggests. In most cases, identity is really correlation. How do I get my car back from the valet? I show the valet a ticket stub with a number that matches ...


0

The id uniquely identifies the BoardGame instance, and it does so independently of any data field values. Composite keys are good for maybe two reasons: readability and platform independence. As sources of identity, they are inferior in almost every other way. They take up too much storage space, and they complicate the indexing process (among other things)...


2

I would like to know how this is handled in an asynchronous environment? In an asynchronous environment, you handle this with a sequence barrier. The second action doesn't get to act on the information until the first action has finished. You have a clear happens-before relation of the two. See, for instance, the work that the LMAX team published about ...


2

What is the importance of not returning domain information in this context? It's a restatement of Command Query Separation, proposed by Bertrand Meyer. Asking a question should not change the answer. In particular, you shouldn't have to change the state of the program to ask a question about it. You’re not really answering why it is important not to ...


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


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

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


0

I would think you'd have one common domain model and then one domain model for each individual. The common model's job is in offering services to consuming clients who don't care about the differences in API of the specific data source. An individual domain model's job is in mapping custom API's into the common model.


0

Generic Repository interface public interface IRepositoryGeneric<TEntity> where TEntity : class { // CRD void Add(TEntity entity); void Remove(TEntity entity); TEntity Get(object Id); IEnumerable<TEntity> GetAll(); void UpdateState(TEntity entity); void Save(); } Repository generic class public class ...


0

You would be breaking the DRY principle putting that validation logic everywhere a zip code is used. On the other hand, when dealing with many different countries and their different zipcode systems, that means you cannot validate a zipcode unless you know the country in question. So your ZipCode class needs to also store the country. But do you then ...


1

Apart from the canonical examples of email addresses or zip codes given elsewhere in this question, Where I find refactoring away from Primitive Obsession can be particularly helpful is with entity IDs (see https://andrewlock.net/using-strongly-typed-entity-ids-to-avoid-primitive-obsession-part-1/ for an example of how to do it in .NET). I have lost count ...


0

The main property of Value Objects (i.e. values) beside that they are immutable is that they are exchangeable. So if I set a value to "3", it doesn't make any difference at all to set it to a "different" "3". 3 is just 3, it's a value. It doesn't really make any difference how you persist it, the important part is that these properties hold. The question ...


0

Database identity and domain identity are not same things, on db level you are allowed to do whatever optimization you need and in domain layer you decide (business requirements) how would you handle your models - as entities or value objects. In relational db's I like to put unique constraint on fields that compose my value object just to be sure to keep ...


2

You are probably having trouble deciding where to put things, because there is no meaningful (i.e. business-related) packages or projects. Let's look at this pragmatically. I see your design 3 levels deep, yet I have no idea what your project is about. Also, let's say you make a change. The client tells you to add a new type of product (or whatever your ...


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


0

You can impose validation in every layer of your application. Where to impose which rules depend on your application. For example, entities implement methods that represent business rules while use-cases implement rules specific to your application. If your building an e-mailservice like Gmail one could argue that the rule "users should have a unique e-...


3

Vaughn Vernon in "Implementing Domain-Driven Design" advises the following: Depending on the purpose of a Domain Service, it can be quite simple to model. You’ll have to decide whether or not your Service should have a Separated Interface [Fowler, P of EAA]. Then also gives the following choices: Interface can be declared in the same package/module ...


1

I think this is a good question to which I don't have a straight forward answer. In short, I think the meta-data/payload distinction is incomplete. Data, Data ... and Data The analogy to HTTP (see VoiceOfUnreason's answer) is a good starting point and quite helpful in understanding the concept of meta data: the data that's relevant to your app is in the ...


0

Like most design decisions the answer is "it depends". Does updating a Foo usually require updating it's collection of Bar as well? Do they need to be updated in the same unit of work? Is Bar a value object? If the answer to one or more of these questions is "yes" then option 2 is probably the only course of action. Under these conditions you can consider ...


3

One of the possible ways to solve this dilemma is to think of SQL as of an assembly language: you rarely, if at all, code directly in it, but where performance matters, you need to be able to understand the code produced by your C/C++/Golang/Rust compiler and maybe even write a tiny snippet in assembly, if you cannot change the code in you high level ...


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


2

I would take a look at one of Microsoft's newer projects code named "Ambrosia" (link will take you to their Github page where the project is being developed open source) which focuses on providing a solution to this exact problem and several other major data consistency problems when developing distributed services. The cliff-notes version is that they ...


2

Conflicts: without implementing another layer of repository which returns Aggregate we cannot even >partly resolve the abovementioned pitfalls by implementing an extra layer of repository we are ignoring the built-in features of EF (every DbSet is already a repo) and over-complicating the app I have used an approach where every Aggregate gets ...


3

With a DDD approach you are trying to match your Entities with the 'Domain Language'. I find it hard to believe that the business says "A User creates a new security token". If they do then sure, the User object should have that method and the required logic for doing the job. But I think it would be more usual for the Business to say "The User logs in" ...


3

Think of it this way, which one represents something meaningful in your domain? Something that somebody familiar with the domain (but not necessarily the technology) would understand. I.e. which one is more likely to be part of the Ubiquitous Language? Option #1: setSecurityToken()? Seems technical, it's a setter. Option #2: createNewSecurityToken()? Seems ...


5

The refresh token is solely defined by its values. And there is no continuity of the object when the values change, because it would be replaced by a new token. This is why it is a value object. This does not prevent that one of the value refers to a given user-id, which gives the impression of continuity between successive values. But it is not ...


0

The most common pattern used to separate a group of entities given invariants that span between them is to break down the use-case into a series of steps and employ value objects/factory methods as a means of communication. I am going to extend your example to help illustrate what I mean. Let us introduce a new concept, Container, to which Boxs are added (...


Top 50 recent answers are included