3

With domain-driven design is best to make tiny steps (change design or code, unit testing ...).

  1. I think that is good (to make the script=to write the code) of SQL Server from SQL Server Management Studio, but with DDD the database code is written at the end, after we tested the design.

  2. With code written in c# and then create database with EF you will change the c# code frequently, and that implicitly will change database code a lot.

How best to proceed?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Blocked
  • 340
  • 2
  • 5
  • 20

2 Answers2

1

DDD preaches persistence ignorance, which states that your domain artifacts (classes for entities, value objects) should be unaware of how they're persisted. However, technical persistence concerns cannot always be easily avoided or delayed. As a result, the model in code will usually be affected by constraints of the persistence technology.

You've already foreshadowed the best approach: tiny steps. The question is what constitutes a step. Initial steps can consist of the designing the model in code and then implementing persistence. A subsequent step repeats the process. The fact that the steps are small reduces the chance that you'll create a design in code which cannot be easily persisted all while prioritizing focus on the model over the database.

Regarding the use of SQL Management studio vs EF generators, this is a matter of preference. I prefer to hand-code SQL, others may enjoy the generation facilities of EF.

eulerfx
  • 36,769
  • 7
  • 61
  • 83
  • Ok,is a matter of preference but what about performance of EF?It is close to sql code performance? – Blocked Mar 26 '13 at 09:20
  • 1
    If tuned to the greatest extent, you can usually get better performance out of raw SQL, but EF can perform well enough given that the suitable indexes are there and the queries don't involve complex joins. – eulerfx Mar 26 '13 at 15:18
1

Assuming you are working on a brownfield project. Then for a given user story:

1) Design and unit test your domain model.

2) Then integration-test your infrastructure. This includes testing repository implementations against database that gets created dynamically for these tests (can be in-memory or embedded). NHibernate generates schema for you automatically, not sure about EF. Being persistence-agnostic definitely helps here because you can test against SQLite but run against SQL Server for example.

3) Then manually write migration scripts for your production database. There is no black magic that will help you with this step. The script can later be executed by a framework like RoundhousE. More information here.

Rinse and repeat. For a green field project that is not deployed yet, you can skip step 3) and generated 'baseline' script on first production deployment.

Community
  • 1
  • 1
Dmitry
  • 17,078
  • 2
  • 44
  • 70