当前位置:网站首页>Discussion: is domain event based layering reasonable?

Discussion: is domain event based layering reasonable?

2021-05-04 15:46:31 Jiedao jdon

Recently, I made a second phase modification to a previous project . In view of the typical anemia structure before , as well as Controller--->Service--->DAO Patterns allow code pressure to focus on service The situation of the layer . In reference to Banq I wrote several articles about the responsibilities and Domain Event Post article , I also tried to work on a new layered model . Post it to discuss with you , Welcome to tile !

【1】 A hierarchy :

① Control layer : Data mapping 、 Steering control 、 Business call

② The business layer : From the user's point of view , See the functional interfaces that the system can provide

③ Physical layer : Entity objects that contain data and behavior

④ Service layer : From the internal point of view of the program , Fine grained functional modules divided to complete business

⑤ Storage layer : Object construction 、 cache 、 Persistence

What I said above may not be very standard , because DDD No careful study , You may have doubts about the business and service layer : My idea here is a business operation from the perspective of users , Corresponding to the inside of the program, it may be divided into multiple fine-grained program operations .

【2】 Collaboration :

① Control layer and business layer :

※ The control layer provides the raw data needed by the business layer , Unsealed data

※ The control layer provides business calls

※ The business layer returns the result to the control layer , It's up to the control layer to turn to

② Business layer and entity layer :

※ The business layer, when necessary (new,edit,delete And so on ), Load objects from the repository

※ Business layer issues event notification to entity layer objects

※ The business layer receives the behavior feedback of the entity

③ Entity and service layer :

※ Entity through “ Service registration ” The way , Let the entity have “ Self data manipulation ” The ability of

※ After the entity receives the event notification from the business layer , Broadcast to registered service providers

※ The service layer provides corresponding operation functions for the entities that need to provide services

※ Entity layer contains entity logic ( You can handle it yourself without relying on other modules 、 level )

※ The service layer contains the service logic ( Cannot be done by an object itself , It involves other objects )

④ Business and service layer :

※ When the business request is a query request , Or when it has nothing to do with the characteristic object , The business layer requests the service layer directly

※ The service layer can be seen as the internal implementation of the business layer request

⑤ Service layer and storage layer :

※ The object entity of storage layer can be : newly build , cache , Load... From persistent media

※ The repository layer contains the Builder, Otherwise build and verify

※ The storage layer includes object caching and caching operations

※ The repository layer includes access to the persistence layer

⑥ Entity and storage layer :

※ The ultimate object of warehouse layer construction is entity , Warehousing is the source of entities , It's also the ultimate destination of the entity

Here are two cases to illustrate the collaboration process :

【3】 Add, delete, and modify the collaborative process of the request

The control layer captures the request , And decide which business layer object to handle

|---> The business layer needs to build / Or a single entity

|---> New from storage (insert) Or load it from the cache (edit,delete), And return the entity , Registration service

|---> Issue an event notification to the entity object (save, update, delete)

|---> Entity objects traverse their registered services , Broadcast the event

|---> The service layer handles the event , Call the storage layer

|---> The warehouse layer performs persistence operations , And return the result

|---> Receive event handling results , And back to the control layer

|---> According to the business layer results , Decide to turn

【4】 The collaborative process of query request

The control layer captures the request , And decide which business layer object to handle

|---> The business layer requests the service layer directly ( Because the request has nothing to do with a single entity )

|---> The service layer processes the request logic , And call the storage layer

|---> The storage layer can retrieve data from the cache , Or take... From persistent media , And back to

|---> Receive query results , And back to the control layer

|---> According to the business layer results , Decide to turn

【5】 Doubts and worries

① Is this stratification reasonable ? Because I want objects to decouple from the service layer through events ?

② This kind of command 、 Will the separation of queries make the future logic scattered and difficult to maintain ?

③ In the process of warehouse construction , It may be necessary to call the service layer logic , Will it cause service <---> Two way dependence and coupling of warehousing ?

Wrote a lot of ~~~ Thank you for your trouble . I really don't want to go back to the days of anemia model

[ The quilt pengpenglin On 2010-03-23 16:37 A modified ]



版权声明
本文为[Jiedao jdon]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/05/20210504154434492z.html

随机推荐