The first wave of advanced DDD actual combat (5): Develop a direct sales system for the general business of the big health industry (realize the product context field layer)

Starting from this article, we formally entered the development of the direct selling system case according to the previous DDD theory and the constraints of the DDD framework.

This article mainly talks about the main implementation of the domain layer in the context of the product. First, briefly talk about the business requirements: product SPU and product SKU, product SPU is mainly the name and related description of the product,

Product SKU includes multiple specifications of product SPU, and each specification has different price and PV value. From our understanding of the DDD concept, product SPU and product SKU belong to the same aggregate, and product SPU is the aggregate root.

 

The product context mainly realizes the product listing function. In order to realize the listing function, we must first realize the domain POCO model and domain logic of the product context.

We build the product's POCO model and domain logic into a project called Product.Domain.

Product SPU Domain Object POCO Code:

 public partial class ProductSPU : IAggregationRoot
    {
        [Key]
        public Guid Id { get; set; }
         public string Code { get; set; }
        public string ProductSPUName { get; set; }
        public string ProductSPUDes { get; set; }
        public List<ProductSKU> ProductSKUS { get; set; }
       
    }

Product SKU field object POCO code:

public partial class ProductSKU : IEntity
    {
        public ProductSKU() { }
        [Key]
        public Guid Id { get; set; }
        public string Code { get; set; }
        public string Spec { get; set; }
        public Unit Unit { get; set; }
        public decimal PV { get; set; }
        public decimal DealerPrice { get; set; }
        public byte[] Image { get; set; }
        public Guid ProductSPUId { get; set; }
        public string ProductSPUName { get; set; }
        
    }

As you can see from the above code, ProductSPU inherits from the aggregate root interface, ProductSKU inherits from the entity interface, and ProductSPU contains a collection (that is, a reference) of ProductSKU, which means that they belong to the same aggregate.

When persisting, it will be persisted uniformly as a transaction.

In addition to its own attributes, the domain object should also include its own business logic. The function of product launch is relatively simple, and the business logic is relatively simple, mainly how to generate the entire domain object, and the generation rules of the aggregate root and entity business identifier Code.

Product SPU domain object business logic code:

 public partial class ProductSPU
    {
        public ProductSPU CreateProductSPU(Guid id,string spuname,string spudesc,List<ProductSKU> productskus)
        {
            this.Id = id;
            this.Code = "Code " + spuname;
            this.ProductSPUName = spuname;
            this.ProductSKUS = productskus;
            this.ProductSPUDes = spudesc;
            return this;
        }
    }

Product SKU domain object business logic code:

 public partial class ProductSKU
    {
        public ProductSKU CreateProductSKU(string productspuname,Guid productspuid,
            byte[] image,decimal dealerprice,decimal pv,string unit,string spec)
        {
            this.Id = Guid.NewGuid();
            this.ProductSPUId = productspuid;
            this.Code = "Code " + productspuname + spec;
            this.ProductSPUName = productspuname;
            this.Image = image;
            this.DealerPrice = dealerprice;
            this.PV = pv;
            switch (unit)
            {
                case "盒":
                    this.Unit = Unit.盒;
                    break;
                case "包":
                    this.Unit = Unit.包;
                    break;
                case "瓶":
                    this.Unit = Unit.瓶;
                    break;
            }
            this.Spec = spec;
            return this;
        }
    }

I divided the properties of the domain object and the logic of the domain object into different cs files to facilitate the development and management of people with different responsibilities, and use the same namespace and Partial keywords.

In addition to implementing domain logic, Product.Domain also defines the repository interface of ProductSPU, and defines the mapping relationship between product context and database context through EF Core.

Repository interface definition:

 public interface IProductRepository
    {
        void CreateProduct<T>(T productspu) where T : class, IAggregationRoot;

    }

As can be seen from the above, this interface actually defines the interface for persisting the aggregate root of ProductSPU to the database.

Product context and database context mapping relationship:

1. Because the mapping relationship is implemented using EF Core, it may be replaced in the future, so first define a product context interface:

public interface IProductContext
    {
    }

2. EF Core mapping implementation

 public class ProductEFCoreContext:DbContext,IProductContext
    {
        public DbSet<ProductSPU> ProductSPU { get; set; }
        public DbSet<ProductSKU> ProductSKU { get; set; }
        protected override void OnConfiguring(DbContextOptionsBuilder optionBuilder)
        {
            optionBuilder.UseSqlServer( " Database Connection String " );
        }

    }

3. Use the EF Core tool to generate the database script and update the database. When generating the script, you need to edit the project file and use the EF Core Tools command to generate it. The technical aspects of EF Core will not be discussed in detail here.

At this point, we have basically implemented the domain layer of the product context. We can see that the domain layer is mainly domain logic, defining a repository interface to decouple the database technology. Of course, we must define the mapping relationship between the domain objects and the database, otherwise The use case can't be done really

Persistence of domain objects.