New answers tagged

0

If transactional correctness requires one aggregate knowing about the current state of another aggregate, then your model is wrong. In most cases, transactional correctness is not required. Businesses tend to have tolerance around latency and stale data. This is especially true of inconsistencies that are easy to detect and easy to remedy. So the command ...


1

You need a data-cleansing exercise. You don't have a chance in hell of writing decent code that will work if the existing data breaks the rules you're trying to establish. Your code is not at fault if it enforces rules on new data, but can't handle old data that - from the sound of it - wouldn't know a rule if one walked up to it and said hello. Your code ...


5

How should I deal with this legacy data that "breaks the rules". So the starting point is to talk to your domain experts. What do they do with the "invalid" data in the legacy system today? Also, is the legacy system the book of record? or does it describe entities that are actually controlled somewhere else? A mix of both? You may need to consider ...


8

Perhaps it is too naive, but did you consider making a fresh database for your fresh application and writing some converter from the old (badly designed) database to the new one? That converter would be hard to code, but you'll get some more cleaner data from it.


1

a very simple That would probably take DDD off the table. If you aren't anticipating a rich and subtle domain model, then you are likely past the point of diminishing returns. Why can't I just build a CRUD app If you are asking this question, it's another hint that DDD may not be the right horse. But taking it straight -- the problem with a CRUD ...



Top 50 recent answers are included