You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Domain model pattern provides an object-oriented way of dealing with complicated logic. Instead of having one procedure that handles all business logic for a user action there are multiple objects and each of them handles a slice of domain logic that is relevant to it.
17
+
The Domain Model pattern aims to create a conceptual model in your software that matches the real-world system it's designed to represent. It involves using rich domain objects that encapsulate both data and behavior relevant to the application domain.
12
18
13
19
## Explanation
14
20
@@ -24,300 +30,121 @@ Programmatic Example
24
30
25
31
In the example of the e-commerce app, we need to deal with the domain logic of customers who want to buy products and return them if they want. We can use the domain model pattern and create classes `Customer` and `Product` where every single instance of that class incorporates both behavior and data and represents only one record in the underlying table.
26
32
27
-
Here is the `Product` domain class with fields `name`, `price`, `expirationDate` which is specific for each product, `productDao` for working with DB, `save` method for saving product and `getSalePrice` method which return price for this product with discount.
if (ChronoUnit.DAYS.between(LocalDate.now(), expirationDate)
70
-
<DAYS_UNTIL_EXPIRATION_WHEN_DISCOUNT_ACTIVE) {
43
+
Data Access Objects (DAOs): These objects provide an abstract interface to the database. They are used to retrieve domain entities and save changes back to the database. In the provided code, CustomerDaoImpl and ProductDaoImpl are the DAOs.
// Implementation of the methods defined in the CustomerDao interface
48
+
}
74
49
75
-
returnMoney.zero(USD);
76
-
}
50
+
publicclassProductDaoImplimplementsProductDao {
51
+
// Implementation of the methods defined in the ProductDao interface
77
52
}
78
53
```
79
54
80
-
Here is the `Customer` domain class with fields `name`, `money` which is specific for each customer, `customerDao` for working with DB, `save` for saving customer, `buyProduct` which add a product to purchases and withdraw money, `returnProduct` which remove product from purchases and return money, `showPurchases` and `showBalance` methods for printing customer's purchases and money balance.
55
+
Domain Logic: This is encapsulated within the domain entities. For example, the Customer class has methods like buyProduct() and returnProduct() which represent the actions a customer can perform.
In the class `App`, we create a new instance of class Customer which represents customer Tom and handle data and actions of that customer and creating three products that Tom wants to buy.
197
-
71
+
Application: The App class uses the domain entities and their methods to implement the business logic of the application.
198
72
199
73
```java
200
-
// Create data source and create the customers, products and purchases tables
201
-
finalvar dataSource = createDataSource();
202
-
deleteSchema(dataSource);
203
-
createSchema(dataSource);
204
-
205
-
// create customer
206
-
var customerDao =newCustomerDaoImpl(dataSource);
207
-
208
-
var tom =
209
-
Customer.builder()
210
-
.name("Tom")
211
-
.money(Money.of(USD, 30))
212
-
.customerDao(customerDao)
213
-
.build();
214
-
215
-
tom.save();
216
-
217
-
// create products
218
-
var productDao =newProductDaoImpl(dataSource);
219
-
220
-
var eggs =
221
-
Product.builder()
222
-
.name("Eggs")
223
-
.price(Money.of(USD, 10.0))
224
-
.expirationDate(LocalDate.now().plusDays(7))
225
-
.productDao(productDao)
226
-
.build();
227
-
228
-
var butter =
229
-
Product.builder()
230
-
.name("Butter")
231
-
.price(Money.of(USD, 20.00))
232
-
.expirationDate(LocalDate.now().plusDays(9))
233
-
.productDao(productDao)
234
-
.build();
235
-
236
-
var cheese =
237
-
Product.builder()
238
-
.name("Cheese")
239
-
.price(Money.of(USD, 25.0))
240
-
.expirationDate(LocalDate.now().plusDays(2))
241
-
.productDao(productDao)
242
-
.build();
243
-
244
-
eggs.save();
245
-
butter.save();
246
-
cheese.save();
247
-
248
-
// show money balance of customer after each purchase
249
-
tom.showBalance();
250
-
tom.showPurchases();
251
-
252
-
// buy eggs
253
-
tom.buyProduct(eggs);
254
-
tom.showBalance();
255
-
256
-
// buy butter
257
-
tom.buyProduct(butter);
258
-
tom.showBalance();
259
-
260
-
// trying to buy cheese, but receive a refusal
261
-
// because he didn't have enough money
262
-
tom.buyProduct(cheese);
263
-
tom.showBalance();
264
-
265
-
// return butter and get money back
266
-
tom.returnProduct(butter);
267
-
tom.showBalance();
268
-
269
-
// Tom can buy cheese now because he has enough money
270
-
// and there is a discount on cheese because it expires in 2 days
271
-
tom.buyProduct(cheese);
272
-
273
-
tom.save();
274
-
275
-
// show money balance and purchases after shopping
276
-
tom.showBalance();
277
-
tom.showPurchases();
74
+
publicclassApp {
75
+
publicstaticvoidmain(String[] args) {
76
+
// Create customer and products
77
+
// Perform actions like buying and returning products

306
108
307
109
## Applicability
308
110
309
-
Use a Domain model pattern when your domain logic is complex and that complexity can rapidly grow because this pattern handles increasing complexity very well. Otherwise, it's a more complex solution for organizing domain logic, so shouldn't use Domain Model pattern for systems with simple domain logic, because the cost of understanding it and complexity of data source exceeds the benefit of this pattern.
111
+
* Appropriate in complex applications with rich business logic.
112
+
* When the business logic or domain complexity is high and requires a model that closely represents real-world entities and their relationships.
113
+
* Suitable for applications where domain experts are involved in the development process to ensure the model accurately reflects domain concepts.
114
+
115
+
## Known Uses
116
+
117
+
* Enterprise applications (ERP, CRM systems)
118
+
* Financial systems (banking, trading platforms)
119
+
* Healthcare applications (patient records management)
* Complexity: Can introduce complexity, especially in simple applications where a domain model might be overkill.
134
+
* Performance Concerns: Rich domain objects with complex behaviors might lead to performance bottlenecks, requiring careful optimization.
135
+
* Learning Curve: Requires a good understanding of the domain and may involve a steep learning curve for developers unfamiliar with the domain concepts.
136
+
137
+
## Related Patterns
138
+
139
+
* [Data Access Object (DAO)](https://java-design-patterns.com/patterns/dao/): For abstracting and encapsulating all access to the data source.
140
+
* [Service Layer](https://java-design-patterns.com/patterns/service-layer/): Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation.
141
+
* [Repository](https://java-design-patterns.com/patterns/repository/): Mediates between the domain and data mapping layers, acting like an in-memory domain object collection.
142
+
* [Unit of Work](https://java-design-patterns.com/patterns/unit-of-work/): Maintains a list of objects affected by a business transaction and coordinates the writing out of changes.
318
143
319
144
## Credits
320
145
321
-
* [Domain Model Pattern](https://martinfowler.com/eaaCatalog/domainModel.html)
146
+
* [Domain-Driven Design: Tackling Complexity in the Heart of Software](https://amzn.to/3vMCjnP)
0 commit comments