使用域驱动设计最好是做微小的步骤(更改设计或代码,单元测试......)。
我认为 SQL Server Management Studio 中的 SQL Server 很好(使脚本=编写代码),但是在我们测试设计之后,最后使用 DDD 编写数据库代码。
使用 c# 编写代码,然后使用 EF 创建数据库,您将经常更改 c# 代码,这会隐式更改数据库代码。
如何最好地进行?
使用域驱动设计最好是做微小的步骤(更改设计或代码,单元测试......)。
我认为 SQL Server Management Studio 中的 SQL Server 很好(使脚本=编写代码),但是在我们测试设计之后,最后使用 DDD 编写数据库代码。
使用 c# 编写代码,然后使用 EF 创建数据库,您将经常更改 c# 代码,这会隐式更改数据库代码。
如何最好地进行?
假设您正在从事棕地项目。然后对于给定的用户故事:
1)设计和单元测试你的领域模型。
2)然后集成测试您的基础设施。这包括针对为这些测试动态创建的数据库(可以是内存中的或嵌入式的)测试存储库实现。NHibernate 会自动为您生成架构,不确定 EF。与持久性无关在这里肯定会有所帮助,因为您可以针对 SQLite 进行测试,但可以针对 SQL Server 运行。
3)然后为您的生产数据库手动编写迁移脚本。没有任何黑魔法可以帮助您完成这一步。该脚本稍后可以由RoundhouseE之类的框架执行。更多信息在这里。
冲洗并重复。对于尚未部署的绿地项目,您可以跳过第 3 步)并在第一次生产部署时生成“基线”脚本。
DDD 宣扬对持久性的无知,它指出您的域工件(实体的类、值对象)应该不知道它们是如何持久化的。然而,技术持久性问题并不总是容易避免或延迟。因此,代码中的模型通常会受到持久性技术的约束。
您已经预示了最好的方法:微小的步骤。问题是什么构成一个步骤。初始步骤可以包括在代码中设计模型,然后实现持久性。随后的步骤重复该过程。步骤很小的事实减少了您在代码中创建设计的机会,该设计无法轻松持久化,同时优先关注模型而不是数据库。
关于 SQL Management Studio 与 EF 生成器的使用,这是一个偏好问题。我更喜欢手工编写 SQL,其他人可能会喜欢 EF 的生成功能。