Domain specification and application function Programming

Synchronized from: http://www.blogjava.net/AndersLin/archive/2006/08/14/63551.html

I have discussed service and object and the associated logic in domain model of small discussion area (ke, I have fixed some points in this article and put them up when appropriate ). Association logic is the focus of this article -- Specification

1. Starting from domain driven design (DDD)
This specification comes from DDD, which has three specification types.
1. Validation
2. Selection
3. Building
However, when I first looked at this specification concept, I believe many people have a similar feeling. In our daily development, the xxxxprovider, xxxhelper, and xxxchecker written based on the SRC principle have also discussed Dao for countless times. This is not the specification. I changed my vest.

Ii. Advantages of specification:
Now is why I want to hold Specification high.
1. Unify the support logic of the domain model to shield the existence of Dao.
Note that this selection is used to retrieve the appropriate object list from the repository (usually a database. Well, this is interesting. It turns out that Dao's position in the system is quite embarrassing,
Due to the previous development philosophy, domain model was the development mode of transaction script. After the emergence of ORM technology, database access was converted from ts to domain to Dao layer, A large number of constraint logics are scattered in the service layer. Therefore, the development system, whether in the system structure (Architecture) diagram (you can refer to appfuse), we see the existence of the DaO layer, and even we are used to the existence of Dao.

The Application of specification unifies these concepts and shields Dao. The most common task of Dao is query logic, and query logic is also a logic. It supports domain model in combination with validation and building. This specification is the name of Dao. However, the concept is correct. If this is the case, I am afraid most people will say "Well, good, but still not practical": If specification is adopted, that is to say, the code under Dao is dispersed, and there is not much benefit, so it is difficult to return it to the crime of Type Expansion. Don't worry about DDD.

2. specification introduces the idea of FP Development
Ddd was not technically poor, and then it proposed the specification closure. Clearly, people will know that closure comes from FP.

Let's take a look at the basic features of functional programming first: 1. Closure Calculation and high-level functions. A function itself is a first class object, and a closure acts as a function and can operate like an object. A high-order function can take a function as a parameter and return a function. 2. Lazy Evaluation) It is calculated not when the function is bound, but when the value is evaluated. 3. recursive computer system 4. Transparent reference The same result returned by the same input is irrelevant to the context. 5. No side effects It cannot be changed after being assigned a value, that is, constant.

Now let's take a look at the combination of the three specification types of DDD.
1. For the combination of validation, DDD also provides the sample code-it's refreshing!
2. The combination of selection, DDD does not give an example. Unfortunately, this selection is difficult because it involves SQL problems (this problem is often linked with performance ). Just some people posted on javaeye to discuss the problem of combination of SQL (http://forum.javaeye.com/viewtopic.php? T = 21760)
My idea is: from the domain object perspective, the range of selection combinations is limited to the clause WHERE and order.
This is the simplest, with no consideration for select and from, or join. The combination of where and order for the same domain object is simple. The and, or, and not operations in the book of DDD are easy to support.
Then we should consider supporting join and union. In my estimation, In the application system: for common SQL statements (without join and union), the ratio of join and Union SQL statements and more complex SQL statements is.
However, Join Processing is really troublesome. I need some additional information. Fortunately, the trial code seems acceptable.
So what should we do for those complex SQL queries (then the remaining 2 )? Simple. Write one program separately. My opinion is that the possibility of reusing things is too complicated. In the future, similar things can be considered to be handled using the Inheritance Method of OO, CO and OO are not mutually exclusive.
In addition to domain object-independent "pages" and "Top N", specification can be provided independently.
(BTW: ajoo said that you can't just say that you don't need to practice it. You have prepared an article with buuawhl on the SQL parser. Learn from idols and try again .)

3. Combination of Building
This looks like curry. I didn't think about it. I will not discuss it for the moment.

In addition, many other logics in the system can be implemented using FP ideas, such as computation in Business Rules (Business Rule Classification in DSL: organizing business rules based on rule systems, for the constraint and action enabler of business rules, you can directly refer to validation.
BTW: ajoo provides some good examples in the javaeye blog.

Iii. Other problems
So far, some seem pretty good. However, there are several issues that have not been solved:
1. Can the Selection Combination problem be implemented.
This... Trying
2. Do you need to write the processing functions of the combined operation for each Specification in development. Can't there be a uniform one.
So far, no. For each specification, the types of parameters, returned objects, and the combination details are different, and we have to process them independently.
2.1 The first is the parameter or the type of the returned object. If it is unified, it will become like this:

Interface action { Object execute (context ctxt ); } Interface context { Object get (string key ); }

Obviously, this is not what we want.
2.2 The other is the combination details:
Buuawhl in http://forum.javaeye.com/viewtopic.php? T = 21533 lists three different types that we should consider.
3. Others
I haven't thought of it yet. I want to talk about it again.