域驱动的设计：使用Blazor UI中的域
我们正在用Gulazor和Azure功能在C＃中创建一个应用程序。
假设我们有以下代码
var trade = //create some trade
trade.AddItems(...)
trade.Save();
添加项目自动计算并记录在交易中的代码。
我们希望能够在UI中添加项目时即时显示费用。在UI中使用上面的域代码以及显示费用的DDD Ethos是否会反对DDD Ethos。
进一步说，允许人们保存交易并稍后返回UI页面，将总的根源（贸易）归还给UI是反对DDD Ethos的吗？
这样做似乎是一种非常简单的方法，但是建议以同样的效率来做到这一点呢？
We are creating a application in C# with Blazor and Azure Functions.
Assume we have the following code
var trade = //create some trade
trade.AddItems(...)
trade.Save();
When items are added fees automatically gets calculated and recorded on the trade.
We want to be able to show the fees on the fly as items gets added on the UI. Would it be against the DDD ethos to use the Domain code above in the ui as well to display the Fees.
Going further lets say one were allowed to save the trade and return to the UI page later, would it be against the DDD ethos to return the aggregate root, Trade, to the ui.
Doing both of these seems like a very simple approach, but what would be recommended way of doing this with the same sort of efficiency?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为您在不同情况下对域模型的使用证明了DDD的力量。
具体而言，域模型可以在不关心它正在执行的基础架构的情况下实现逻辑。
我也有类似的情况，即我在jullazor客户端中使用我的域模型（具有网络断开弹性），也可以在有限的上下文中使用。在服务器上的API后面，记录最终被持续存在。
在客户端中，我使用indexedDB来存储模型，但是在服务器上，我使用的是SQL Server（通过实体框架）来持续相同的模型。同样，我对客户端的命令管道与API背后的管道不同。
该模型并不关心我在它周围使用不同的基础架构，这是DDD的优势之一。
关于将聚合根返回UI，因为总体根最初是在API后面实现的，但是然后在返回客户端的途中被序列化 /进行序列化，我们没有处理相同的“对象”。
我们可能会使用带有相同数据的相同类别的类别来获取客户端的实时业务逻辑结果，但是对原始“对象”的任何更新仍然需要通过您的API进行新的请求。
最后，如果您的域模型不能同时在这两种情况下使用，则可能告诉您您的DDD错误。
I think that your use of the domain model in different situations demonstrates the power of DDD.
Specifically, the domain model can implement logic without a care about the infrastructure it is being executed in.
I have a similar situation where I'm using my domain model in a Blazor client (with network disconnection resilience), but also in the bounded context behind an API on the server, where the records are finally persisted.
In the client, I use IndexedDb for storage of the model, but on the server I'm using SQL Server (via Entity Framework) to persist the same model. Similarly, my command pipeline on the client is different to that behind the API.
The model does not care that I'm using a different infrastructure around it and this is one of the strengths of DDD.
Regarding returning the aggregate root to the UI, as the aggregate root is initially materialised behind an API, but is then serialized / deserialized on way back to client, we are not dealing with the same 'object'.
We may use the same classes populated with the same data to get real-time business logic results on the client, but any updates to the original 'object' would still require a new request via your API.
As a final note, if your domain model cannot be used in both contexts at the same time, it is probably telling you that you've got your DDD wrong.