Thinking about domain-driven design (DDD) warehousing

Why do we need warehousing? Domain objects (typically aggregate roots) are created to last persisted to the database, which requires dealing with the database, so that we need something like the database access layer to manage the domain objects. Is that why we can design something like the DAL layer to manage objects? Yes, but there is a difference in design, that is, we do not want the upper layer as the application tier directly access the data, all of our operations should be around the domain object, so we also designed the warehousing interface in the domain layer, and then put the implementation of warehousing in the infrastructure layer. Such design patterns are common and are commonly used for decoupling. But warehousing does not handle transactions, transaction processing we generally hand over to unitofwork, there are about Unitofwork introduction you can refer to my previous article unitofwork and its application in ABP.

ABP in the design of warehousing ideas, in fact, is also very simple, is to provide domain objects of some common database operations, the general storage of the object is the aggregation of the root, but the ABP does not strictly distinguish the aggregate root, it is simple to all objects as the aggregate root, this design is also seen in NOP. Below I was drawing a class diagram of the ABP warehouse design.

In this class diagram we can clearly see a few:

1, storage design significance, some people say I use EF development dbset<t> is actually a warehousing ah, why do I need to redefine a repository? The answer is obvious in that we may not be sure that we will use other database access frameworks such as NHibernate or MongoDB later in our project. So if I design irepository this interface, if I need to use MongoDB in my project someday, then I can inherit irepository to implement a Mongodbrepositorybase class.

2, abprepositorybase this base class GetAll return is Iqueryable<t> but IQueryable returns a query parser, not a result model. So we have no way to determine what the getall is going to return, there is no way to unit testing and so on. This question has been before the cricket blog repository back to IQueryable? Or a IEnumerable? In the discussion, interested students can refer to the next ha. The general strict DDD is not a direct return to IQueryable, but it doesn't matter if you are not a strict ddd. For this I specifically refer to the next netfocus of the enode of the case forum, specific to see the blog Enode Introduction and various resources summary (continuous update in ... Let's take a look at how the Netfocus expert designs it. Because the forum is not very familiar, I only found the account index warehouse design.

namespace forum.domain.accounts{///<summary>///    Account index information storage interface for storing unique index information of account number, to realize unique constraint of account name//    </summary> public    Interface iaccountindexrepository    {//        <summary> Retrieve account index information by account name        /// </summary>//        <param name= "AccountName" ></param>//        <returns></returns>        accountindex findbyaccountname (string accountname);        <summary> Add an account index///</summary>//        <param name= "index" ></param>        void ADD (Accountindex index);}    }

Next is how the infrastructure layer is implemented

namespace forum.domain.dapper{[Component] public class Accountindexrepository:iaccountindexrepository {            Public Accountindex Findbyaccountname (string accountname) {using (var connection = getconnection ()) {connection.                Open (); var data = connection. Querylist (New {accountname = AccountName}, constants.accountindextable).                Singleordefault (); if (data! = NULL) {return new Accountindex (data).                AccountId As String, accountname);            } return null;            }} public void Add (Accountindex index) {using (var connection = getconnection ()) {connection.                Open (); Connection. Insert (New {AccountId = index. AccountId, AccountName = index.            AccountName}, constants.accountindextable);        }        }Private SqlConnection getconnection () {return new SqlConnection (configsettings.connectionstring); }    }}

From the above we can know that it uses the data access technology is dapper, not EF, it also has no IQueryable design, need to find what, such as Findbyaccountname, this is strictly in accordance with the DDD model of the warehouse design. This design and ABP design have advantages, look at the project needs it. At this point my warehousing also summed up here, I am also a beginner of ddd, may have some understanding is not in place, hope to learn from each other to grow together. Blog Park has a lot of similar articles, this is mainly designed to ABP related, as an ABP series of an article.

Reference article:

Http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html

Http://www.cnblogs.com/xishuai/p/repository-return-iqueryable-or-ienumerable.html

Http://www.cnblogs.com/jesse2013/p/ddd-repository.html

Thinking about domain-driven design (DDD) warehousing