Domain modeling or data modeling

Domain modeling or data modeling?

(a) Users do not care “objects”. They care UI, and the fact that the data on the UI are saved in databases. So, by definition, UI and the key data are the “business language”; objects are not.

(b) The pragmatic inevitability of Anemic Domain Model http://www.martinfowler.com/bliki/AnemicDomainModel.html-- OK, just in case I am not clear enough, I am saying that although sounds terrible, anemic domain model is a good thing. -- Just as others pointed out, OR mapping encourages this. Again, a lot of people believe it is a bad thing (and therefore, OR mapping is a bad thing!), I believe it is a good compromise.

(c) Part of the reason of (b) is that > 80% of the function of an application is “data CRUD”; so, why bother domain model.

(d) Because of all above, domain model can be “skipped” at least for smaller projects; for larger projects, it is certainly a good exercise. However, even in the latter case, the first-cut of the major database tables should be done first; therefore, the key objects should be “copied” from data model. The key reason is, of course, users (see (a)). This is crucial. You may find ways to “bypass” the data modeling phase, and say that you start with a “domain model”. However, if you think of the reason how you get the major objects done, it is always “we need those key data”! OK, the value of being honest to ourselves? – Time saving: > 90% of the domain model can be done within one or two days, after data model is done. And data model is much easier to do, because you can get help from users directly. You may say, how about the rest 10%? – Those are the low-level objects, they are implementation oriented; and we should not talk about them with users anyway.

(e) Fit can fit in perfectly, even when we do not use domain modeling. The key is data.