5

I am writing DDD bounded contexts with some entities using event sourcing for their persistence and other entities using SQL databases.

To simplify writing of the entities that use SQL persistence, given everything is controlled via the entity in the domain layer is it common practice to skip the notion of referential integrity against foreign keys? Can these integrity checks on foreign keys be excluded from the underlying databases entirely?

If so this would reduce complexity in any ORM, and reduce the stores to standalone tables with the entity domain layer handling the relational mapping between.

Are there any pitfalls against this approach? So far i cant see any when using entities to control everything.

Improve this question
6
  • 4
    Keep foreign keys in your database. It's not too much extra work and clarifies intent a lot.
    – Andy
    Commented Aug 3, 2017 at 21:08
  • not to mention the database actually enforces referential integrity.
    – Hannah Vernon
    Commented Aug 3, 2017 at 21:38
  • I'm wondering if you are thinking that because some entities are in separate BC's that you might forego integrity in the individual BC's? If that is the motivation, there are better ways of handling that.
    – Erik Eidt
    Commented Aug 3, 2017 at 23:33
  • 2
    Are you sure that what you need is a relational db?
    – Laiv
    Commented Aug 4, 2017 at 7:35
  • 2
    Data integrity aside. David Packer pointed to something important (IMO). The db constrains are like roads in a road map. If you remove the roads. What did you get? A bunch of desconected points. There's nothing to read. Constrains give us certainty and determinism at the moment of facing changes. And trust me, the only application that doesn't changes is a dead one.
    – Laiv
    Commented Aug 4, 2017 at 9:36

1 Answer 1

Reset to default
11

I briefly worked at a company where they decided to not add database integrity constraints on any of the tables because they were planning on relying on the ORM and correct programming to ensure the integrity of the database.

To put it mildly it was a massive failure. Code mistakes had caused the database to lose integrity, and at the time I joined about 1/2 of development time was fixing bugs from data integrity problems that could have been avoided with proper database constraints.

On top of that, trying to explore and understand the schema was very difficult. You could only guess at the columns that were intended to be foreign keys by the column's name and type. Schema diagramming tools don't work because they rely on foreign keys to map the relationships.

Your programs may contain bugs, or you may misconfigure something, so you shouldn't rely on programs to maintain the integrity of your database. Also you may wish to connect tools directly to the database at some point, and those will be free to cause mayhem on your data integrity without constraints. If I were in your position I would rather be safe than have to fix data inconsistencies in the future.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.