Retrieved from http://www.jdon.com/42751
Recently, I revisited the original book of domain-driven design and gained some new understanding. Now I think I can better understand the following paragraph that jdon007 said earlier.
"User requirements" cannot be equated with "users", and capturing "models in users' minds" cannot be equated with "designing domain models with users as the core". There is a point of view in the book "Lao Zi": what is useful is beneficial, and what is not is useful. Here, the advantage is to establish a domain model; the useless is to accommodate user needs. For example, a cup needs to be filled with a cup of water. When we make a cup, we make an empty cup, that is, we need to pour out the water before we can put it in. For another example, a house needs to live in, and when we build a house, The built house is empty, and only empty space can accommodate people. Therefore, when building a domain model, users should also be placed outside the model, so as to accommodate the needs of users.
Therefore, my understanding is: when we design domain models, we can't think about problems with the user as the starting point, and we can't always think about what users will do to the system; instead, we should dig out the domain according to user needs from an objective point of view. related things, thinking about the essential relationship of these things and their changing laws as a starting point to think about problems.
Let's take a simple example of a cargo transportation system in Eric Evans (the father of DDD) in his book.
After some discussion of user requirements, Eric described the domain model as follows:
1. A Cargo (goods) involves multiple Customers (customers, such as shippers, consignees, payers), each Customer Take on different roles;
2. Cargo's delivery target has been specified, that is, Cargo has a delivery target;
3. A series of Carrier Movement (transportation actions) that meet the Specifications are used to complete the transportation target;
From the above description, we can see that he does not describe the domain model from the user's point of view at all, but takes the related things in the domain as the starting point, and considers the essential correlation of these things and their changing laws. For example, point 1, if it is user-centric, it becomes: a shipper can consign goods, that is, it has the behavior of consigning goods, a consignee can receive goods, and a payer needs to pay; and his The description is completely centered on the goods, and the customer is regarded as the related "things" that the goods may involve in a certain scenario. For example, the goods will involve multiple customers, the goods have a definite target, and the goods will go through a series of columns. In fact, I think that the user-centered thinking of the domain model only stays on the surface of the demand, without digging out the essence of the real demand; we need to work hard to explore the user demand when doing domain modeling.
This makes me think that the starting point when I thought about the book lending system was wrong, because I always thought about the problem with the user as the center .
For example, borrowers borrow books, borrowers return books, administrators store books, etc. After the above analysis, I think I should think about domain models with books as the core starting point. For example:
1. A book can only be borrowed by one person at a time, or it is not borrowed and left in the library;
2. When the book is returned, it needs to check the return time, and if it is overdue, it needs to be fined;
3. A book has inventory information, such as book storage location, inventory quantity;
4. …
Instead of describing the domain model from the user's point of view, it takes the related things in the domain as the starting point.
It seems that there are two clues for cognitive analysis needs, one is human-centered needs analysis;
As for which one is the main focus, it still depends on how much people and things play roles in different scenarios. For example, in the freight system, we can also see a freight-based transportation system from this name. Therefore, , people should be in a secondary position.
But in the case of library borrowing, I personally think that it is not an autonomous movement with books as the mainstay, but a system with people as the mainstay and books as the auxiliary. If books are the mainstay, "books are borrowed". Fantastic things happen, hehe.
People != users
For example, in a population file management system, there should be information about people recorded in the system or there is a model about people, but the model of this person does not represent a user.
In the library management system, if the user group is "readers", then "readers" (users) should be excluded from the model; if the user group is librarians, then "readers" (no longer users, even if they are named users) , which can be placed in the model (for example, to mine the user interest model to find out what kind of books people like to read).
In logistics system, if the user group is "customer", then "customer" should be placed outside the model; if the user group is "manager", then "customer" (which is no longer the user of the system) can be placed in the model. Inside.
Putting "users" in addition to "models" is easier to do when there is a single user group; if there are multiple user groups with different natures, it should be noted that different user groups will have different mental models, although there are differences between them. There may be an intersection.
However, this principle should be followed even when the mental models of diverse user groups are brought together, and there is a need to be conscious of potential changes in perspective (which may be overlooked or forgotten, leading to confusion).
On the whole, "book", "account", and "book library" are models (including their structure/state and functional/behavioral features), which can be understood as the structural composition of the system; "borrowing rules" are scene specifications or Business rules can be understood as the operating rules of the system.
The mental model of the user (reader) includes not only books, but also accounts (book cards), bookstores (libraries), etc. The model has state and behavior, but it is constrained by the scene specification when participating in the interaction of the scene.
An idea that can be tried is to discover models from business rules (scenario-aware, scene specifications extracted from them), and to separate business rules from models as a whole, so that models are freer, so that they may be reused in different scenarios. Business rules, or adapt to changes in business rules.
As for the organization of the model, you can learn from the PPT of the four-color prototype , such as library examples: Place(Library), Party(Account), Thing(Book), or borrowing OO 's message-based ideas to classify models as object+message or event+handler/dispatcher; of course, there are Other methods of classifying or organizing models.
Users of the model should not be included inside the model. ...
当你确定书是核心领域模型了，那么模型的使用者是不应该包含进来进行分析，通过借书这样一个事件 或场景的发生，模型的使用者与模型发生了关系，这时模型书还是需要一个使用者的记录的。
模型：
Class Book{
String id;
String name;
}
用户操作借书事件 激活借书服务，从而发生借书场景：
Class BookContext{
boolean borrow(Book book);
}
当borrow(Book book)事件被调用以后，拉了一泡屎，留下状态，这个书被借了，借阅者是某个用户，在数据表中我们可能有这样的记录：
book{
String id;
String borrowedUserId;
}
至于，这个borrowedUserId字段是否应该出现在Book模型中，则是另外一种设计考虑，比如我们认为borrowedUserId字段应该属于Book的状态，那么出现在BookState中比较合适，那么Book类有了一个新引用BookState:
Class Book{
String id;
String name;
BookState bookState;
}
Class BookState{
Book book;
User borrowedUser;
Date returnDate;//归还日期等
}
完毕。
我把整个过程列出来，是为了理清我们的思绪，不要让模型的状态去影响我们的分析。
以上这个分析的唯一前提是：假设这个系统是以书为核心，跟踪围绕书发生的各种事件 。
所以，我们在描述时不能以“书被借”这样去描述需求，会产生误导，因为“借书”是一个事件 ，而“书被借”是一个状态，状态是事件 的结果，事件是状态的因，而模型是事件 的核心，没有模型，事件就无法发生，就象没有电话，就没有电话铃这个事件 ，没有书，就不会有借书这样的事件 。
由以上倒退，我们知道，分析一个需求，核心模型是第一步，这一步是不应该考虑用户，前提是如果这个用户是在事件 发生时介入的话；但是如果这个用户不是事件 介入发生，而是属于模型一部分，如书的作者，那么就应该考虑用户。
我的观点是：天地不仁，以万物为刍狗。
千万不要以为是人就扔掉：驱动者和参与者的区别。在领域当中的“人”，与“刍狗”等同，没有特殊地位。在整个领域世界中，应该全是逻辑描述，即使是人，也应该以简单对象来理解，构成事实离不开万事万物。
试想一个互动功能，交朋友，没有任何独立于人的实物，把人扔掉会是什么样的效果呢？
理解驱动者与参与者区别，就可以走出误区，account很容易让人想到使用者，分开Passport和Reader不就行了？Reader是人吗？是，但他完全和Book的地位一样，“刍狗”一只而已。
“以用户为中心”的思想主要来自于登录系统——认为系统事件 参 与者就是现实世界中的用户。虽然这样的观点在一定程度上可行，但这种关联只是一个潜在的认为而已——经过登录后，认为某个现实用户（或者电脑，或者仪器， 或者IP）所发出的所有命令是系统中与这个登录所绑定的“人”发出的。这种关联是通过登录后获得，也就是说，若果没有登录，这两者应该是分离的，是两个独 立的个体。