标签: domain-driven-design

谷歌帮不了我。我只找到这个链接：http : //flylib.com/books/en/2.522.1.56/1/

那么，一旦出现问题 - 为什么我们需要划分 Product 和 Item ？

遵循 CQRS（命令查询职责分离）的概念，我在我的 MVC 应用程序中直接引用 DAL，并通过 ViewModel 进行所有读取。然而，我的一位同事问我，当阅读时必须应用任何业务逻辑时，你会怎么做。例如，如果您需要在如下场景中计算百分比值：

//Employee domain object
class Employee
{
    string EmpName;
    Single Wages;
}

//Constant declared in some utility class. This could be stored in DB also.
const Single Tax = 15;

//View Model for the Employee Screen
class EmployeeViewModel
{
    string EmpName;
    Single GrossWages;
    Single NetWages;
}


// Read Facade defined in the DAL
class ReadModel
{
    List<EmployeeViewModel> GetEmployeeList()
    {
        List<EmployeeViewModel> empList = new List<EmployeeViewModel>;
        string query = "SELECT EMP_NAME, WAGES FROM EMPLOYEE";      
        ...
        .. …

我有一个包含 2 个子域的域。

每个子域都包含对另一个子域的一些依赖关系。

我想将每个子域放入一个单独的程序集中（我想将其拆分为1st:vertical 2nd: horizontal modules =>easy reusability）。

问题是：

我如何管理不同的依赖项sub domains（每个依赖项都放在一个单独的程序集中）

和

我在正确的道路上吗？

我有一个特定的场景，其中聚合具有检查地址是否有效的行为。此验证是通过网站上的内联 ajax 表单验证在聚合上触发的。在聚合和网站之间是协调两者的应用程序服务。

就目前而言，我创建了一个本质上是空的聚合并设置了地址属性，以便可以完成检查。基于此，我将 true 或 false 返回到网站 (ASP.NET MVC)。在 DDD 的上下文中，这似乎不是正确的方法。

    public bool IsAddressAvailable(string address)
    {
        var aggregate = new Aggregate
                             {
                                 Address = address
                             };
        return aggregate.IsAddressValid();
    }

我有哪些选择可以更好地使用 DDD？我正在考虑将其分离为域服务。任何意见，将不胜感激！

假设我有一个对象，它在大多数情况下具有两个不同应用程序的必要属性等，因为两个应用程序都需要使用它们。有可能 10% 的属性不会在一个应用程序中使用。共享该对象（并将聚合/有界上下文作为共享内核？）还是复制存储的属性和数据更好？一个应用程序用于最终用户/活动，另一个应用程序用于管理用户/活动。

我想使用事件源和 CQRS，所以我需要投影（我希望我使用正确的术语）来更新我的查询数据库。如何处理数据库错误？

例如，我的一个查询缓存数据库不可用，但我已经更新了其他数据库。因此，当它恢复业务时，不可用的数据库将不会与其他数据库处于 snyc 中。它如何知道它必须运行例如来自事件存储的最后 10 个域事件？我想我必须存储有关数据库当前状态的信息，但是如果该数据库状态存储失败怎么办？任何想法，最佳实践如何解决此类问题？

我试图了解 InputModel 和 ViewModels 在 4 层架构中的位置。

介绍 | 应用 | 域 | 基础设施

鉴于应用层负责表示层和域层之间的交换数据，我认为它们必须位于该层内，以及将其转换回域实体的适配器，反之亦然。

InputModels，也称为 Commands，在 ASP.NET MVC 中它们可以与 ViewModels 重合。

演示文稿中的 ViewModels 对我来说毫无意义。从应用程序层，我应该将 ViewModels 返回到 Presentation 并接收 ViewModels 以将其映射回域实体。如果我在 Presentation 中有 ViewModels，并且 Presentation 是指应用程序层，我将有一个循环引用。

而且，例如，如果我在 ASP.NET MVC 中构建了一个 Presentation 并且我有必要为 Windows 应用程序更改它，我将失去这个适合我的必需品的 ViewModels，这太可惜了，因为我已经拥有了一切内置改变演示技术。

我正在阅读来自 Dino Esposito 和 Andrea Saltarello 的书，Microsoft .NET: Architecting for the Enterprise。他们没有过多谈论应用层，只是说，这一层应该编排域服务和存储库以完成用户案例，并将域从演示文稿中隐藏。

这是正确的吗？我应该把这个 DTO 放在应用层中吗？如果没有，它们在 Lasangna 上的什么位置？

我正在练习 DDD，我有一个非常简单的例子，目前看起来像这样：

Polling
    getEventBus() -> Bus
    getEventStorage() -> Storage
    getMemberRepository() -> MemberRepository
    getCategoryRepository() -> CategoryRepository
    getBrandRepository() -> BrandRepository
    getModelRepository() -> ModelRepository
    getVoteRepository() -> VoteRepository

MemberRepository
    MemberRepository(eventBus, eventStorage)
    registerMember(id, uri)
        -> MemberRegistered(id, uri, date)
        -> MemberRegistrationFailed //when id or uri is not unique
    isMemberWithIdRegistered(id)
    isMemberWithUriRegistered(uri)

CategoryRepository
    CategoryRepository(eventBus, eventStorage) {
    addCategory(id, name)
        -> CategoryAdded(id, name, date)
        -> CategoryAdditionFailed //when id or name is not unique
    isCategoryWithIdAdded(id)
    isCategoryWithNameAdded(name)
};

BrandRepository
    CategoryRepository(eventBus, eventStorage) {
    addBrand(id, name)
        -> BrandAdded(id, name, date)
        -> BrandAdditionFailed //when id …

我正在开发一个简单的DDD +基于事件采购的应用程序,用于教育目的.

为了在存储到事件存储之前设置事件版本,我应该查询事件存储,但我的直觉告诉这是错误的,因为它会导致并发问题.

我错过了什么吗？

我正在研究在没有事件存储的系统中采用域驱动设计中的（根）聚合概念的可能性。但是，我对两者的了解越多，就越觉得一个没有另一个就不可能存在。

我还没有读完蓝皮书，但是到目前为止，我对根聚合的理解是，它是聚合的“树”，需要在该根聚合内保持一致。聚合只能通过其所属的根聚合进行修改。最后，根基本上可以通过“定义此聚合独立性是否有意义，并且它是否可以单独存在于此域中”来定义。

想象一下一个绿地项目，在该项目中尚未进行事件采购的工程设计，但将来可能会从中受益。没有事件存储将消除跟踪在特定时间点影响根聚合的所有域事件的可能性。这些命令将必须突变根聚合。另外，由于没有事件可重播性，读取端将被限制对“根聚合{id}已更新”做出反应。

在没有事件存储的情况下，是否存在任何合理的方式来存在（根）聚合的概念，还是应该坚持“传统”实体建模，直到有意义地投资于事件采购为止？