In 91

其實這一篇只是做個讀書筆記，memo一下書上對domain model角色的定義。

雖然這本書是在講java的，但是以modeling來說，是沒有語言區分的。

 

從Manning POJOs in Action這本書上的摘錄：

There are several different naming conventions for roles. My favorite scheme is based on the one in Domain-Driven Design [Evans 2003] and has the following roles:

• Entities—Objects with a distinct identity
• Value objects—Objects with no distinct identity
• Factories—Define methods for creating entities
• Repositories—Manage collections of entities and encapsulate the persistence framework
• Services—Implement responsibilities that can’t be assigned to a single class and encapsulate the domain model

詳細一點的定義：

1. Entities
   Entities are objects that have a distinct business identity that is separate from the
   values of their attributes. Two entities are different even if the values of their
   attributes are the same and cannot be used interchangeably. Identifying entities is
   important because they often correspond to real-world concepts and are central
   to the domain model. Examples of entities in this application are PendingOrder,
   Order, and Restaurant.
2. Value objects
   Value objects are objects that are primarily defined by the value of their attributes.
   They are often immutable, which means that once they are created they cannot
   be updated. Two instances whose attributes have the same values can be used
   interchangeably. Examples of value objects in this domain model include
   PaymentInformation and Address.
3. Factories
   A Java application creates objects by using the new operator. Sometimes, using the
   new operator directly is sufficient, but if you need to instantiate a complex graph
   of objects or you need to vary the types of the objects that are created, then you
   might need to use a factory. A factory defines methods for creating entities. It
   encapsulates the mechanism that instantiates a graph of objects and connects
   them together, which simplifies the client code.
4. Repositories
   Repositories manage collections of entities and define methods for finding and
   deleting entities. They can also play the role of factories if the factory code is sim-
   ple. A repository encapsulates the persistence framework and consists of an inter-
   face and an implementation class. The interface defines the methods that can be
   called by the repository’s client, and the implementation class implements the
   interface by calling the persistence framework. Because the persistence frame-
   work is encapsulated behind an interface, you can focus on developing the busi-
   ness logic without being slowed down or distracted by database issues.
5. Services
   The fifth and final kind of objects that are found in a domain model are services,
   which implement the workflow of the application. These classes are the driving
   force of the application, with the methods that fulfill a use case. Generally, ser-
   vices include behaviors that cannot be assigned to a single entity and consist of
   methods that act on multiple objects. An example of a service in this domain
   model is PlaceOrderService, which defines methods corresponding to the steps
   of the Place Order use case.
   A service consists of an interface and an implementation class. It is invoked by
   the domain model’s client, which is either the facade or the presentation tier. A
   service method rarely implements a significant amount of business logic. Instead,
   a typical service method retrieves objects using a repository and then delegates to
   them. For example, PlaceOrderService calls RestaurantRepository and Pending-
   OrderRepository and mostly delegates to PendingOrder.
   The methods defined by a domain model service are very similar to those
   defined by a session facade or a POJO facade. The methods usually correspond to
   the steps of the use case. However, a service, unlike a facade, doesn’t deal with such
   things as performing transactions, gathering the data that must be returned to the
   presentation tier, detaching objects, and all of the other things that the facade has
   to deal with. Instead, it just focuses on pure business logic. Keeping the service sep-
   arate from the facade is useful because you can work on the service and the rest of
   the domain model without worrying about “plumbing” and other infrastructure
   issues. In fact, as you will see in the next section, the service is a good place to start
   when implementing a domain model.

 

附上一張domain model pattern的架構圖：

其他書籍推薦

註一：如果對domain model有興趣，且又極度的不想看java，那推薦可以看Applying Domain-Driven Design and Patterns: With Examples in C# and .NET
註二：如果對software architecture有興趣，想瞭解透徹一點，可以看Patterns of Enterprise Application Architecture

---

blog 與課程更新內容，請前往新站位置：http://tdd.best/