小编Nay*_*qui的帖子

我最近开始尝试使用.net-core(nuget包)的EventStore客户端API .但是,我正在努力让事件写入流中.下面是我用来建立连接的代码:

    private readonly string _eventStoreName = "localhost";
    private readonly string _eventStorePort = "1113";
    protected IEventStoreConnection Connection;

    public EventStoreTestFixture()
    {
        var eventStoreIpAddress = Dns.GetHostAddressesAsync(_eventStoreName).Result;
        var ipAddress = GetIpAddressFromHost(eventStoreIpAddress);
        var connectionSettings = ConnectionSettings.Create()
            .SetDefaultUserCredentials(new UserCredentials("admin", "changeit"))
            .EnableVerboseLogging();
        Connection = EventStoreConnection.Create(connectionSettings,new IPEndPoint(ipAddress, int.Parse(_eventStorePort)));
        Connection.ConnectAsync().Wait();
    }

    private static IPAddress GetIpAddressFromHost(IPAddress[] eventStoreIpAddress)
    {
        return
            eventStoreIpAddress.FirstOrDefault(
                ipAddress => ipAddress.AddressFamily.Equals(AddressFamily.InterNetwork));
    }

这是我试图写入EventStream的代码:

public class EmployeeEventSourcedRepository<T> where T : class, IEvenSourced
{
    private readonly IEventStoreConnection _connection;

    public EmployeeEventSourcedRepository(IEventStoreConnection connection)
    {
        _connection = connection; …

根据有界上下文，我们已经确定了两个微服务实现，我们分别调用它们Service A和Service B。每个微服务都有不同的存储库（由于单一职责和更好的所有权的好处）。现在，每个存储库都使用自己的数据库架构（选择是为了更好地分离持久性并减少数据库实例的维护）。

之前，我们将数据库迁移脚本（用于持续交付）提取到单独的单个存储库（包含 和Service A模式Service B的脚本）中，并在 CI 下的单个作业下运行它们。现在，当我们处理更多的故事时，我们开始面临一些挑战，其中一些挑战如下：

• 对单个模式的更改会触发整个数据库的构建，从而触发所有微服务的下游，从而增加我们的反馈时间
• 我们通常无法实现true持续交付，因为架构更改也需要相应的代码更改Service，因此部署两个PR时都需要谨慎
• 此外，还有一些公共表Users需要由两个模式使用，这些表目前正在两个模式之间复制。

所以我的问题/疑问是：

• 我们是否应该根据模式分离数据库迁移存储库，就像服务一样。
• 我们是否应该为数据库迁移脚本建立单独的存储库？我们应该将它们合并到各自的Service存储库代码中吗？
• 我们是否应该进一步提取通用表a level up并筹集Domain Events资金Eventual Consistency

任何指示/建议都会有很大帮助。谢谢。

所以我对将某些东西称为域对象（并最终将类放在域包下）几乎没有怀疑。

我有一个微服务，它的职责是做一些计算（在不涉及实际业务需求的情况下，它所做的只是根据给定的请求计算一些兴趣的回报）。现在为了实现计算，需要进行某些子计算，因此分别在不同的类中组成。但是，是的，这些计算不需要保存在 DB 中，而且它们都没有 ID（所以绝对不是实体或聚合）。然而，这些单独的计算器类（由于缺乏术语）确实包含一些复杂的业务逻辑。现在，我的问题是，这些单独的类是否仍然符合/分类为域对象，还是应该将它们称为服务？

如果需要，请随时要求对用例进行更多说明。

干杯！