A library to facilitate communication between CommandService and QueryService. The Idea is when any event occures in commandService, it should be persisted in QueryService in MongoDb
نحوه برقراری ارتباط بین #C و Event Store از طریق تعریف اینترفیس شبکه و اختصاص IP در docker-compose
version: '3.4'
services:
eventstoresample:
image: eventstoresample
build:
context: .
dockerfile: EventStoreSample/Dockerfile
networks:
clusternetwork:
ipv4_address: 172.16.0.12
eventstore:
image: eventstore/eventstore
environment:
- EVENTSTORE_INT_IP=172.16.0.13
- EVENTSTORE_EXT_HTTP_PORT=2113
- EVENTSTORE_EXT_TCP_PORT=1113
- EVENTSTORE_EXT_HTTP_PREFIXES=http://*:2113/
ports:
- "1113:1113"
- "2113:2113"
networks:
clusternetwork:
ipv4_address: 172.16.0.13
networks:
clusternetwork:
driver: bridge
ipam:
driver: default
config:
- subnet: 172.16.0.0/24
Bridge Network Driver
The bridge networking driver is the first driver on our list. It’s simple to understand, simple to use, and simple to troubleshoot, which makes it a good networking choice for developers and those new to Docker. The bridge driver creates a private network internal to the host so containers on this network can communicate. External access is granted by exposing ports to containers. Docker secures the network by managing rules that block connectivity between different Docker networks.
Overlay Network Driver
The built-in Docker overlay network driver radically simplifies many of the complexities in multi-host networking. It is a swarm scope driver, which means that it operates across an entire Swarm or UCP cluster rather than individual hosts. With the overlay driver, multi-host networks are first-class citizens inside Docker without external provisioning or components. IPAM, service discovery, multi-host connectivity, encryption, and load balancing are built right in. For control, the overlay driver uses the encrypted Swarm control plane to manage large scale clusters at low convergence times.
MACVLAN Driver
The macvlan driver is the newest built-in network driver and offers several unique characteristics. It’s a very lightweight driver, because rather than using any Linux bridging or port mapping, it connects container interfaces directly to host interfaces. Containers are addressed with routable IP addresses that are on the subnet of the external network.
As a result of routable IP addresses, containers communicate directly with resources that exist outside a Swarm cluster without the use of NAT and port mapping. This can aid in network visibility and troubleshooting. Additionally, the direct traffic path between containers and the host interface helps reduce latency. macvlan is a local scope network driver which is configured per-host. As a result, there are stricter dependencies between MACVLAN and external networks, which is both a constraint and an advantage that is different from overlay or bridge.
In short, domain events help you to express, explicitly, the domain rules, based in the ubiquitous language provided by the domain experts. Domain events also enable a better separation of concerns among classes within the same domain.
It's important to ensure that, just like a database transaction, either all the operations related to a domain event finish successfully or none of them do.
Domain events are similar to messaging-style events, with one important difference. With real messaging, message queuing, message brokers, or a service bus using AMQP, a message is always sent asynchronously and communicated across processes and machines. This is useful for integrating multiple Bounded Contexts, microservices, or even different applications. However, with domain events, you want to raise an event from the domain operation you are currently running, but you want any side effects to occur within the same domain.
The domain events and their side effects (the actions triggered afterwards that are managed by event handlers) should occur almost immediately, usually in-process, and within the same domain. Thus, domain events could be synchronous or asynchronous. Integration events, however, should always be asynchronous.
public sealed class DepositUseCase : IDepositUseCase
{
private readonly IAccountReadOnlyRepository _accountReadOnlyRepository;
private readonly IAccountWriteOnlyRepository _accountWriteOnlyRepository;
public DepositUseCase(
IAccountReadOnlyRepository accountReadOnlyRepository,
IAccountWriteOnlyRepository accountWriteOnlyRepository)
{
_accountReadOnlyRepository = accountReadOnlyRepository;
_accountWriteOnlyRepository = accountWriteOnlyRepository;
}
public async Task<DepositOutput> Execute(Guid accountId, Amount amount)
{
Account account = await _accountReadOnlyRepository.Get(accountId);
if (account == null)
throw new AccountNotFoundException($"The account {accountId} does not exists or is already closed.");
account.Deposit(amount);
Credit credit = (Credit)account.GetLastTransaction();
await _accountWriteOnlyRepository.Update(
account,
credit);
DepositOutput output = new DepositOutput(
credit,
account.GetCurrentBalance());
return output;
}
}
Account
A bank account allows us to send and receive money and has its unique number. Anytime we tell about an account in a bank, an account is always a bank account. In the other hand, an account in an information system is used to authorize a user. We have the term "account" meaning something absolutely different in two different domains. Domain has an impact on what we imagine when someone says a concrete term. So we have to learn and specify domain terms first.
Price
Let's speak about e-shop domain. What is a price? For us, as customers, it is how much we pay. A manager can think about price as an amount that his company pays to the supplier. For an accountant, a price is just a number. And e-shop programmer is now confused.
Language is crucial because customers and experts are telling their stories in their language. But it is also natural language, inaccurate, ambiguous, context-aware. And as we can see, language can be tricky even within one domain.
