Getting started with the Enode framework: How event-driven architecture (EDA) ideas are embodied in the framework

Open Source Address: Https://github.com/tangxuehua/enode

In my previous article, I shared a framework enode based on DDD and EDA architecture, but I just introduced a ballpark. Next I'm going to use a lot of detailed but not lengthy articles to introduce each point. Try to get one at a time without introducing too much content, but hopefully after each introduction you will be able to let everyone know the idea of this small point of design, as well as to solve the problem.

Well, this article, I mainly want to introduce the EDA ideas in the framework of Enode how to reflect?
Implementation of domain-based service for classical DDD

General applications, if a user action involves the modification of multiple aggregation roots, we typically create a unit of work in the application-tier service, and then we might design a domain service class where multiple aggregate roots are modified in the domain service class, and then the application-tier service will have the entire unit of Changes in work are committed to the database in a transactional manner at once. This approach is a transactional approach to implementing strong consistency involving multiple aggregate root modifications. Take the classic scenario of bank transfer as a case study:

public interface Ibankaccountservice {void TransferMoney (GUID sourcebankaccountid, GUID targetbankaccountid,
    Double amount);
        public class Bankaccountservice:ibankaccountservice {private Icontextmanager _contextmanager;
    
        Private Transfermoneyservice _transfermoneyservice;
            Public Bankaccountservice (Icontextmanager ContextManager, Transfermoneyservice transfermoneyservice) {
            _contextmanager = ContextManager;
        _transfermoneyservice = Transfermoneyservice;
            } public void TransferMoney (GUID sourcebankaccountid, GUID targetbankaccountid, double amount) { using (var context = _contextmanager.getcontext ()) {var Sourceaccount = context.
                Load<bankaccount> (Sourcebankaccountid); var Targetaccount = context.
                Load<bankaccount> (Targetbankaccountid); _transfermoneyservice.transfermoney (Sourceaccount,Targetaccount, amount); Context.
            SaveChanges (); }
        }
    }

A bank transfer, the core of the action is the source account transfer money, the target account into the cash; Of course, the actual bank transfer is certainly not so simple, and certainly not so. I take this as an example to analyze how we do this if a user scenario involves more than one aggregation root modification, based on the classical DDD approach. As shown in the above code, we may design an application-tier service, such as the ibankaccountservice above, which has a TransferMoney method for implementing bank transfer functions. And then the application-tier service further invokes a domain-level transfer service, the Transfermoneyservice in the code above, which, according to Eric Evans, should be a verb-named service, A domain service can clearly correspond to an area of business meaning in the field of action, this example is "transfer", so I designed a transfermoneyservice in the name of the domain service, the service TransferMoney method to achieve the core of bank transfer Business logic.

In the example above, according to the classical DDD, we should implement the Process control logic and the transaction in the application layer, so you can see that in the above code, we first get a unit of work, the context in the code above, and finally call the story. SaveChanges method, the responsibility of this method is to commit all modifications of the current context to the database in a transactional manner. Well, the above example we analyzed the classical ddd about how to implement a user scenario that would involve creating or modifying multiple aggregation roots;