EntityFramework Field Driven design Practice (iii): A simple sales system

Case: A simple sales system

From now on, we will take a simple sales system as an example to explore the application of entityframework in the field-driven design. To facilitate discussion, our sales system is very simple and does not involve customers having multiple delivery addresses or any inventory management content. Suppose our system only needs to maintain product type, product and customer information, and be able to help customers place orders, track order status, and accept customer returns. From a simple analysis we can generally understand that the system will have the following entities: Customers, documents, products and their types. The documents are divided into sales orders and return orders, and each document can have multiple document lines, such as sales order lines and return orders lines. Not only that, the system allows each customer to have multiple credit cards, so that when the checkout, choose a credit card to pay. After using the EF entity Data Model Designer to design, we get the following model:

The above model describes the relationships among entities in the domain model. Let's not talk about the entire system's business, let's look at how the EF supports the concepts of entities and value objects first.

Entity

First look at the concept of the entity. In the theory of domain-driven design, an entity is an object in a model that needs to differentiate between individuals, that is, for a certain type, we need to know what it is and what it is. I have introduced the concept of the entity in the previous blog post. Entities have an identifier that distinguishes them from other entities of the same type. The EF Entity Data Model Designer All the entities you can draw, you see that each entity has an ID member, the Entity key property is set to True, and an identifier is assigned, as shown in the following illustration: