| There are lots of variations on how the Domain Model pattern is used. I asked a couple of friends of mine to describe their favorite ways of applying Domain Models. As the input, they got the requirements listings from Chapter 4, "A New Default Architecture," and you will find their answers here in Appendix A.[1] I'll repeat those requirements here for you: [1] Please note that when they received the input, the idea was to require an application server in the scenario, something I changed later on for Chapter 4.
List customers by applying a flexible and complex filter. The customer support staff needs to be able to search for customers in a very flexible manner. They need to use wildcards on numerous fields, such as name, location, street address, reference person, and so on. They also need to be able to ask for customers with orders of a certain kind, orders of a certain size, orders for certain products, and so on. What we're talking about here is a full-fledged search utility. The result is a list of customers, each with a customer number, customer name, and location. List the orders when looking at a specific customer. The total value for each order should be visible in the list, as should the status of the order, type of order, order date, and name of reference person. An order can have many different lines. An order can have many order lines, where each line describes a product and the number of items of that product that has been ordered. Concurrency conflict detection is important. It's alright to use optimistic concurrency control. That is, it's accepted that when a user is notified after he or she has done some work and tries to save, there will be a conflict with a previous save. Only conflicts that will lead to real inconsistencies should be considered as conflicts. So the solution needs to decide on the versioning unit for customers and for orders. (This will slightly affect some of the other features.) A customer may not owe us more than a certain amount of money. The limit is specific per customer. We define the limit when the customer is added initially, and we can change the amount later on. It's considered an inconsistency if we have unpaid orders of a total value of more than the limit, but we allow that inconsistency to happen in one situation and that is if a user decreases the limit. Then the user that decreases the limit is notified, but the save operation is allowed. However, it's not allowed to add an order or change an order so that the limit is exceeded. An order may not have a total value of more than one million SEK. This limit (unlike the previous one) is a system-wide rule. (SEK is the Swedish currency, but that's not important.) Each order and customer should have a unique and user-friendly number. Gaps in the series are acceptable. Before a new customer is considered OK, his or her credit will be checked with a credit institute. That is, the limit discussed previously that is defined for a customer will be checked to see if it's reasonable. An order must have a customer; an order line must have an order. There must not be any orders with an undefined customer. The same goes for order lines, they must belong to an order. Saving an order and its lines should be atomic. To be honest, I'm not actually sure that this feature is necessary. It might be alright if the order is created first and the order lines are added later on, but I want the rule to be like this so that we have a feature request related to transactional protection. Orders have an acceptance status that is changed by the user. This status can be changed by users between different values (such as to approved/disapproved). To other status values, the change is done implicitly by other methods in the Domain Model.
First up is Mats Helander with the variation he calls "Object-oriented data model, smart service layer, and documents." Here goes. |
