4 ms·

> For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then aft

> For complicated apps you should think domain or business problem first. Model your domain, make it good for reasoning about your business issues, and then afterwords think about persisting that to a database. Yes, you should design your work first, and figure out what type of data you need to store, and how it should be stored. Just about any application that uses Oracle cannot be "adapted" to use mongodb. It's an entirely different scope, different persistence model, different features... If we were comparing mysql vs postgres, there would be novel-sized comments about how you can't just switch between them. mysql : postgres :: bicycle : recumbent bicycle mongodb : oracle :: tricycle : underwater nuclear submarine They're just soluctions to entirely different business problem domains. This kind of "if the architecture is clean enough it can run on your microwave" attitude is a disease.

UK-AL 9y ago
Well if you model your domain, then if you find only a certain database can persist that domain well, then write a specific adapter for that database and stick with it. If your using DDD + OO most of the adapter will be converting to and from your persistence model and your domain model. However there are plenty of applications why there is no technical reason why they can't work on both though.
- Chyzwar 9y ago
  Nope, data abstractions always leak. Writing application for Oracle I know that I have ACID and transactions, Writing my data access layer I will take advantage of this. I will also consider locking issues and add some kind of cache like Redis to boost read performance. Writing for MongoDB I have schemaless data and different consistency guarantees. Because my data objects do not have consistent schema my access layer need to be flexible enough to deal with object of different shape. I would probably use dynamic languages like JS/Ruby. Database choice will guide design and implementation data access layer. It is non trivial to change this. Even MySQL to PostgreSQL can take a lot effort when you have a lot live data.
  - UK-AL 9y ago
    That's the thing your persistence adapter is a separate thing to your domain. You can implement it however you want.
    - Chyzwar 9y ago
      Your domain representation is your data. How you store/interact with your data will depends on storage. You cannot decouple this unless you create adaptor with only lowest common denominator. How you will create an adaptor that support transaction for both Mongo and Oracle? Answer: You don't because Mongo do not support transaction. This is like fridge and bookshelf. Both provide storage but cannot be used interchangeably. What would be adaptor for bookshelf to store meat?
      - UK-AL 9y ago
        Well it isn't usually much of problem in DDD because between aggregates eventual consistency is used. Only for a single aggregates is all work is expected to fully completed for an action which mongo is fully capable of.

UK-AL 9y ago

Well if you model your domain, then if you find only a certain database can persist that domain well, then write a specific adapter for that database and stick with it. If your using DDD + OO most of the adapter will be converting to and from your persistence model and your domain model. However there are plenty of applications why there is no technical reason why they can't work on both though.

Chyzwar 9y ago
Nope, data abstractions always leak. Writing application for Oracle I know that I have ACID and transactions, Writing my data access layer I will take advantage of this. I will also consider locking issues and add some kind of cache like Redis to boost read performance. Writing for MongoDB I have schemaless data and different consistency guarantees. Because my data objects do not have consistent schema my access layer need to be flexible enough to deal with object of different shape. I would probably use dynamic languages like JS/Ruby. Database choice will guide design and implementation data access layer. It is non trivial to change this. Even MySQL to PostgreSQL can take a lot effort when you have a lot live data.
- UK-AL 9y ago
  That's the thing your persistence adapter is a separate thing to your domain. You can implement it however you want.
  - Chyzwar 9y ago
    Your domain representation is your data. How you store/interact with your data will depends on storage. You cannot decouple this unless you create adaptor with only lowest common denominator. How you will create an adaptor that support transaction for both Mongo and Oracle? Answer: You don't because Mongo do not support transaction. This is like fridge and bookshelf. Both provide storage but cannot be used interchangeably. What would be adaptor for bookshelf to store meat?
    - UK-AL 9y ago
      Well it isn't usually much of problem in DDD because between aggregates eventual consistency is used. Only for a single aggregates is all work is expected to fully completed for an action which mongo is fully capable of.