The Value Of Domain Models

When, and why, is it valuable to implement a DomainModel in an ObjectOrientedProgrammingLanguage? The premise that we should do so is one of the forces in the context of the ObjectRelationalImpedanceMismatch problems.

I confess that I haven't really examined this question very thoroughly. Rather, we have been conditioned since the late 1980s by the OOA literature to believe that doing so is "the right thing" to do. I'm not saying I disbelieve the rationale - I think I do believe in the rationale. I just want to reaffirm that, in hindsight, the experience has delivered upon the promise.

Without going back to check in all of my OOA books, I think the arguments for doing so are along the lines of the following summary:

1. Implementing a DomainModel in an ObjectOrientedProgrammingLanguage results in an organization of code that is more understandable than in competing approaches, because the resulting code is organized in a way (with classes) that is "isomorphic" to the manner in which we "view the world".

2. Implementing a DomainModel in an ObjectOrientedProgrammingLanguage results in an organization of code and logic, a factoring of responsibilities, that is more flexible, maintainable, and extensible than in competing approaches, because, due to encapsulation, functionality can be changed with minimal impact to client code and because, due to the use of classes as an organizing principle and to programming-by-specialization, functionality can easily be added to an existing codebase.

Has this turned out to be true in practice? I guess I feel that way. I confess I haven't had too much experience with defining record types and structs in languages like Pascal and C, and passing them around to functions and procedures, and seeing what happens several years into the lifespan of the codebase, but I do vaguely remember doing things like that early in my career (fortunately for me, I discovered Smalltalk early on ;-)

I suspect that a lot of programmers use DomainObjects as "dumb data holders" with little behavior other than methods to access and mutate state information. I know this is one of RebeccaWirfsBrock's pushbuttons, and I think the types of responsibilities that programmers allocate to DomainObjects is a key factor in the answer to the question.

The amount of opportunity you have to allocate meaningful behavioral responsibilities to DomainObjects is, I think, largely dependent on the problem domain you're working in, and the type of application you're building. I suspect a lot of information systems basically reduce to CRUD operations on DomainObjects in relatively simple DomainModels. But there are some classic examples of when there is great opportunity to allocate significant computational responsibility to DomainObjects: trading systems, for example, in which a diverse investment portfolio is responsible for answering its current market value in an arbitrary currency. As another example, a recipe in FoodSmart is responsible for answering the nutrition profile of a serving of itself, which is a fairly complex computation.

What has been the collective experience of the WikiCommunity? How behaviorful are your DomainObjects?

There are alternatives. One can use DomainObjects as "dumb data holders" and allocate computationally intensive responsibilities to other parts of a codebase. But this has the potential to separate function from data, and negate the advantages enumerated above. Or, one can avoid DomainObjects altogether, and just schlep ResultSets? back and forth between the presentation layer and the persistence layer. I've seen one application built this way, and it is not very maintainable or extensible.

Let's explore this important question. What are your thoughts and experiences?

--RandyStafford

Digression on ForwardEngineeringFromCaseTools moved there. Digression on FunctionsAndDataAreSeparate moved there. Digression on metaphors and cognitive science moved to MetaphorsAndCognition.

Now let's get on with the main thread. Thanks, RandyStafford

Thanks for refactoring Randy. But in the course of refactoring something got lost. You stated you understand DomainModels from an implementation perspective, as opposed to (or not close to) a logical data model.Is this still the case ?

Sorry about the lossy refactoring. I appreciate both the conceptual and implementation perspectives of domain models - what I stated was that historically (IMHO) Smalltalkers have predominantly used the phrase "domain model" to refer to the implementation perspective.

Does a domain model (in the wide acceptance of the term) still has to define responsibilities that are attached to data ? -CostinCozianu

Overall I would say yes - every OO methodologist who's ever written about OOA and object models includes discussion of behavioral responsibilities, and the "behaviorist" camp of RebeccaWirfsBrock and CrcCard users has responsibilities as its central focus. But for me, a lot depends on what my purpose is at a given time. For example, I've found that early in a project, when I'm just trying to understand what are the abstractions in a problem domain and how they relate to each other (i.e., the conceptual perspective), I'm not tremendously concerned about responsibilities at that time - I know they are inherent. However, when subclassing a framework to code domain objects, and when implementing use cases in code and trying to decide where in the codebase to locate required behavioral responsibilities of the system, at that time I'm very concerned about responsibilities. -- RandyStafford

Here's a thought experiment. Let's say you are writing an application without making any effort to create a domain model in the above sense. Let's further assume the application has a database in the background. You are trying to separate concerns, and you are trying to keep related data and behaviour together.

In the course of your design/refactoring activities, you will probably create some classes that the database data is mapped to. Furthermore, you will probably move any behaviour into these classes that is closely related to their data. Would these classes emerge to constitute a full-blown domain model? If not, how would they be different? -- FalkBruegmann

I think you may be performing a "name" experiment above, rather than a "thought" experiment, Falk. Here's why. You may not be thinking the words "domain model", but you are "trying to separate concerns", and these activities are identical, more or less. Your experiment definitely contrasts design-up-front with experiential design, but the fact that you code a little, then think a little, then code a little, etc. doesn't make your design any less "domain model", does it?

I'm not familiar with Smalltalk lingo and idioms, and I guess maybe that's why I didn't "get" this page for a while. I've had a similar argument with people where I work on the subject of how Entity Beans should be used. My argument is that Entity Beans methods ought to be "interesting", meaning they should bear the responsibility of maintaining proper state changes in the system (also known as "business rules"), while much of the literature reduces them to holders for a row in a table, essentially having only property setters and getters and load and store methods. I haven't built a system using Entity Bean yet, so I don't know the gotchas firsthand of treating them as full-fledged objects. Guess I'll have to go there soon.

This is, indeed, a key question, Randy. The title really threw me off the scent, though. -- WaldenMathews

Sorry about the obscure title, Walden. I'm not sure how many alternatives there are to "DomainModel" - maybe "BusinessObjectModel?"? I'm glad you perservered and brought up entity beans, because I think the "value" issue applies to them as well. After all, entity beans and "plain old java objects" are just two different ways to implement a conceptual domain model. Regardless of which implementation path you choose, the question is when is it worth your while to go through the pain of creating an implementation bean/class for every abstraction in your conceptual domain model? If you already have database tables to store the data, what justifies ObjectRelationalMapping over simpler data access approaches? -- RS

Walden, thanks for your remarks. I'll to clarify my words. When I hear "Domain Model", I think of something coming from analysis, a model of the domain as the domain experts see it. When I was talking about "separation of concerns", in this case, I was thinking about technical concerns, such as cyclical dependencies or feature envy in the code.

Therefore, my Gedankenexperiment can be rephrased like this: Suppose you have two persons independently working on the same problem. Person A starts to work with the customer, trying to find good abstractions that model the domain. Person B starts with a set of attributes and a set of functionality, and then aggressively refactors those according to purely technical concerns, also arriving at an object-oriented model.

Now the question is: Will the two models be similar? -- FalkBruegmann

EricEvans is working on a book on DomainModelling, under the working title of Domain Driven. The models he is talking about are the ones in the heads of the programmers and customers. In a way, what he's talking about sounds a lot like XP's SystemMetaphor. -- JohnBrewer

Going back to the original discussion, I must say I haven't contested a priori the value of domain models/ business object. However there are several problems with the "domain models" approach, and those problems aren't acknowledged in the OO literature that Randy made reference to. These problems warrant that a MultiParadigm? approach might work better than just sticking with the idea that we'll do OO analysis, OO design and OO implementation all the way, thinking in terms of business objects and domain model only, and of course following the well know cook books for "mapping objects to tables".

What are these problems ?

the quality of database schema. Coming from an OO analysis perspective the likelihood to have a lousy data modeling experience is close tyo 100%, at least for a large class of applications that I've had experiences with. The OO school of thinking (and I refer here to the mainstream like Wirfs Brooks, the three amigos, the books in the UML series - those white hard covers with the mandatory UML in the title that cover in excess of 50% of the bookstore's OO shelves) , because I can quote other less known authors who considered these problems ) has no criteria for asserting the quality of a database schema or as a matter of fact an object model, and "object architects" are usually not trained to spot these problems. More they suffer from some serious misconceptions, chief among which they attach an OID to almost every table - if not to all tables, and some of them even publish such data antipatterns in printed books. A relational perspective in data modeling is almost always needed.
The cost/benefit factor of the approach. It is well known that certain classes of problems/use-cases require a lot less coding in other paradigms ( like functional programming/ logic programming/ SQL programming even/ and event-driven component based programming). For a lot of use cases I can warrant that I can have the whole thing ready in something like Delphi in a matter of minutes, before anybody else will even have the business objects, the controller and the views ready for coding. I'll always want a case by case basis approach to how to get a specific thing done.
The quality of some OO frameworks. Don't even try to bring EntityBeans into discussion here. At the current state of affairs (EJB 2.0) they're doomed for any but the most simple cases where you don't need them anyway. Some O/R mapping products are better, but still they're far from reaching the point where using them exclusively will not prevent you from using a RDBMS to its full power.

So my thinking goes that if you want to avoid these problems, be prepared not to see everything through OO lenses. In certain situations it is clear that designing and implementing business logic in terms of business object classes is a good approach, but not always. -- CostinCozianu

The Shlaer-Mellor object models begin unabashedly with relational schema, and further, if you've understood entity relation modeling and you're now studying OO domain models or conceptual modeling (as I believe they call it in UML), you'll notice some striking similarities and might even experience one of those "nothing new" epiphanies. Costin's comments above made me wonder: "Does OO have anything equivalent to normal forms in database design?" If not, it's an oversight. In essence, I think Costin is saying that OO modeling can be done crappily, and therefore it would be sane to supplement the techniques with other vantage points in order to get better thought coverage. And I'd be inclined to agree.

Does not the "impedance mismatch" resolve down to one fundamental difference between object design and relational design, namely that an object reference is a complete way of identifying an object, while a table primary key requires the rest of the database context to make it real? That's probably just me, jumping to conclusions without thinking enough, but I'd appreciate the kindness of anyone willing to comment on that, or perhaps help draw it out more.

-- WaldenMathews

There is a terrible oversight in most of OO modeling schemes (and UML is good case for that) in that the identification problem is all but skipped, and this might lead to serious consequences in practice. But this is not the only problem. To make a stronger claim I would say that just by only applying OO principles and concepts as they are popular today ( and I wish we can do something more to get rid of what I see as the bad influences in OO ) the probability of a bad design is very significant. And in practice this is even more apparent than in theory. -- CC

"Does OO have anything equivalent to normal forms in database design?" If not, it's an oversight. In essence, I think Costin is saying that OO modeling can be done crappily, and therefore it would be sane to supplement the techniques with other vantage points in order to get better thought coverage.

DevilsAdvocate: Is it really an oversight? There is no mathematical form form symphonies or paintings yet we are still able to judge the completeness of these work. Well before XP came along, ComputerScience professors professed to see elegance and beauty in languages and systems and these concepts aren't going away.

If you think that just by applying XP principles you are miraculously going to solve your database design problems, I can assure you are wrong. If you think there is no mathematical form in symphonies, again you are wrong. And there's a lot of musical theory underneath those symphonies, too, although not necessarily mathematical. If you think these kind of comparisons bring more light, I'll throw one more in: like any pop musician ain't gonna write no symphony, no OO guru who disregards database concepts and principles is gonna write a good database schema. -- CC

DevilsAdvocate: Which can first, though? Beautiful symphonies came before any mathematical descriptions of them. Music came before music theory. In these cases, theory was deduced from existing reality. Perhaps the same approach should be explored for OO. What mathematical forms can be derive by examining intuitively elegant OO models?

What is the development history of NormalForms?

Beware the WaterFall thinking here. "Music came before music theory." Yes, just as the egg preceded the chicken, but in a more practical sense, they evolved together through interaction with each other and with the ears of humans. (If you're wondering about the interactions between eggs and human ears, you haven't lived through Halloween in my town!) But I digest...

If you want to have a SoftwareGarden?, go ahead, but I think that's off topic for this page. I assume we are talking about design methods that support some rigor and repeatability, not just the luck of the draw. -- WaldenMathews

Arguably, "normal forms" <=> "contract assertions".

That's not true as far as I can see. But if you can see more than I do, please give some details.

But do we mean domain model here, or do we mean object model and is there a difference? -- whm

When I started this page, I intended to mean "domain model" as traditionally used. Yes, a domain model is an object model, but it is a special kind of object model. It is not an object model of a set of GUI components, or of a file system, or something "infrastructural" like that. Rather, the idea is this: you're building a system that needs to manipulate a model of some problem domain. In my experience the problem domain usually concerns a set of abstractions that are important to a business. Taking a telecommunications example, you might have abstractions like Customer, Account, Service, Feature, etc. In a hotel reservation system example, you might have abstractions like Hotel, Room, Reservation, Guest, etc. Early in the project you will sit with some subject-matter experts and learn what are the important abstractions in the problem domain, what are the relationships between them, and what are their attributes. Perhaps you will cast the knowledge into a (conceptual) UML class diagram, or into a "logical data model" expressed as an entity-relationship diagram (the two are more or less equivalent for this purpose). Now, here is where the interesting part begins. Assuming the system will use an both object-oriented programming language and relational database, two things are likely to happen. One, somebody will take the conceptual model and translate it (perhaps one-for-one) into a set of classes in the OOPL. Two, somebody will take the conceptual model and derive a relational schema from it. My question is, how valuable is it to have the set of classes in the OOPL under these assumptions? -- RandyStafford

How polymorphic are the objects?

What does it matter?

It seems to me that the key differentiator between relational models and object models is polymorphism. If true, the value of having a set of classes in an OOPL is directly related to the value of using polymorphism in the resulting implementation. Am I missing something?

No, it's a good point - and it kind of assumes that the OOPL classes are implementing some meaningful, computational, and perhaps polymorphic behavior. This is exactly what I'm struggling with: there can be a lot of pain associated with implementing and maintaining a DomainModel - namely, the ObjectRelationalImpedanceMismatch, and the problem of DomainObjectStateDistribution? (which is addressed by the DataTransferObject/DomainObjectStateHolder patterns). If one insists on implementing a DomainModel in a three-tier architecture with relational persistence, one necessarily suffers this pain. But there are a number of ways to avoid it: don't implement a DomainModel, don't use distributed architecture, don't use relational persistence, etc. We've been conditioned by the OOA mavens to think DomainModels are unconditionally valuable; but if, due to the nature of the problem domain, they don't implement any behaviors more meaningful than simple getters and setters, then perhaps they are not justified. -- RandyStafford

One of the problems I'm having with this page (from the start) is that I'm not getting precise meanings from the language. For instance, I've been wondering what it means to "implement a domain model". Does it mean to build such a model (including apart from writing code)? Or does it mean to write code in which the objects are exactly and none other than the objects of the (perhaps imagined) model?

According to DanielJackson, and this thinking I have adopted because I find it clarifying, an object model has nothing to do with object oriented programming, at least one does not necessarily imply the other. An object model is a descriptive artifact in which a problem and optionally parts of its solution are expressed as objects. The two salient facts about objects (the things the model has to address) are (1) state invariants and (2) state changes. The former partitions valid states from invalid ones, while the latter partitions among a set of valid sub-states, describing exactly what does and does not change.

Object orientation (still according to Daniel) applies to programming languages, and includes such features as inheritance and polymorphism. These have to do with how you structure code, primarily. It's not necessary to use an object oriented language just because we are doing object modelling, and I suppose the inverse is also true (but I'm not thinking hard about it now).

A relational model, done with entity relation diagrams, seems to be a subset of the object model defined here: it describes data attributes and groupings, but does not constrain state the same way the object model does. Here, I am willing to listen to other opinions on that. In implementing your database, you may indeed use constraints of various kinds that are built into the database system - that's not the claim. The claim is that this stuff is missing from the models.

The principal value of a domain model (an object model of the problem domain, no?) is its ability to help you figure out whether you described the problem the way you meant to. Coding cowboys have no use for this, as it's "Just Semantics", missing the point that all of systems and all of software is "Just Semantics", but don't get me started on that. Typically, a domain model describes the problem (the objects in the real world, not your software machine), but that's more convention than necessity. "Implementing" or attempting to "implement" the domain model directly errs by mistaking the problem for the solution, even though they seem to have the same shape along their interface (that's why you get away with it!).

Someone please tell me if this intersects in any way the original probings of this page, and I'll be happy to expand as requested or shut up as likewise requested, or perhaps go back to writing silly little limericks.

-- WaldenMathews

This page desperately needs some refactoring, but I'll throw some opinions here nevertheless, since we need to kind of speak the same language and in order to achieve that maybe each of us has to explain his own language. :)

First of all, I agree with Daniel Jackson (though I haven't read it) that Object Orientation is primarily about code structures. And going with OO beyond what it is intended for, especially when you don't have a solid theory behind it, it's a risky enterprise. Just to add to my opinion I would reference to BenKovitz' book "Practical Software Requirements".

But with regards to models there's a lot of confusion going on. The traditional interpretation of modeling for database applications (which has at least the merits that is rigorous and has the right of the first come) is that you have three levels:

Conceptual modeling -> conceptual model. Here you identify the concepts (abstractions in Randy's vocabulary) and the semantics: the relations and constraints/dependecies between them. For doing this you can use a conceptual theory like ExtendedEntityRelationship?, ObjectRoleModeling and a few others that are created specifically for this level. So a E-R diagram reflects the conceptual model.
Logical modeling -> logical data model. Here you implement the conceptual model at a logical level that you have at your disposal. And here the relational model is the best practical model we have for doing that. Many people misuse the term data model for what has been called since the seventies as logical data model, but to avoid ambiguities we can all safely say schema or database schema so there's no room for confusion. See DataModel. Many people think that the conceptual model morphs uniquely into a good database schema, and sometimes this is true, but not always, and the way you design your logical schema may have a significant impact in future development, the quality of data and lots of other stuff.
Physical modeling -> database implementation.Here you take the schema and you put the table into tablespaces, create indices, clusters, partitions and lots of other cool stuff for the DBA to worry about.

Of course you also have to structure the code. Here you can create a object model, usually reflected by a class diagram in UML. Thus you structure your code. It is not always a good technique to structure your code strictly according to the conceptual model, and perform the processing strictly by sending messages to the objects that you derived from the conceptual model (ex: Hotel, Guest, Account). If you do that, you hit the problem of "persisting objects into relational databases, O/R mapping" and other coll sutff, and there's plenty of suffering in there. What is worse is to go from the conceptual model (if any, because this step may be skipped in real life) -> object model, then follow a cookbook recipe to create tables according to the object model ( you can use a tool like TopLink to do this automatically for you), and then great chances are that you hit your head into the wall (ObjectRelationalImpedanceMismatch), although many OO authors preach exactly this approach.

Now to clarify more concepts in this page describing or better said specifying the problem is ( at least for me and a few others) called under the generic name of requirements engineering(/gathering/specification). Identifying the objects/concepts/abstractions in the problem and attaching behaviour to them is by far not enough, and again a OO only thinking will generally hurt you at this stage.

A domain model is a model that describes a domain, but in this page I assumed Randy's interpretation of a collection of business objects and the relations between them.

As such, a domain model applies to a whole domain (for example applies to banking and not just to the Bank X for which I develop the project), and might be any type of model (object model, logical data model, conceptual model) that can either be applied directly to a particular project in that domain, or with slight modification (let's say that Bank X has the same notion of accounts like any other bank, but might have some more specific banking products). Or at least that's my view on what a domain model should name according to common sense English. Unfortunately in software engineering we didn't do a good job of understanding each other.

-- CostinCozianu

I believe that this thread is discussing the aesthetic value of domain models. In other words, does the design and the implementation of the domain model make us feel good on a qualitative, intellectual level. Do I believe that DomainModels provide aesthetic value? I certainly do. I have done some quite elegant designs and implementations using OO DomainModels. They made me feel good intellectually. I could show them off to other software professionals and they would say: "Coooool." However, when it comes down to software engineering, did these aesthetically pleasing DomainModels help me quantitatively? I don't really know. I have a sneaking suspicion that they did but I have no real hard evidence supporting that postulation.

Costin, I believe, makes the critical statement here. "Unfortunately in software engineering, we didn't do a good job of understanding each other". I think that this is biggest problem facing the software industry. I believe that there is practically little to no software engineering in the vast majority of software projects. In come the "silver bullets" in an attempt to ameliorate the problem. Two of the recent biggies are J2EE (specifically EJB) and .NET geared toward distributed systems. Others include CORBA, Garbage Collection and CASE tools (e.g. Rational, TogetherSoft), and of course, ObjectOrientedProgrammingLanguages. All of these technologies are intended to relieve the software programmer from some of the drudgey of software engineering and provide for the management of complexity. These tools and technologies are merely enablers. They are not a replacement for good, solid SoftwareEngineering.

Intrinsic Value vs. Value Proposition

Do DomainModels and ObjectOrientedProgrammingLanguages provide intrinsic value? I don't know. I do know they do, however, provide a Value Proposition. The proposition is: If you do object and domain modelling "right", then you will see "better" software systems and this enhanced value will be the direct result of using object technology. What is the definition of "right" and what is the measure of "better"? I have an inkling but I cannot say, or point to a reference, that will be definitive. This OO value proposition is the spawn of more subjective diatribe than I care to comment on. After time, this diatribe has evolved into dogma. We took the value proposition on faith ... as gospel. It seemed to make sense. I still believe that it makes sense. But I can't necessarily prove it. All I can do is rely on the products of my own meandering experience ... anecdotal evidence. This is not enough to determine the TheValueOfDomainModels from an objective perspective.

Therefore, let's take a look at the value of DomainModels from a perspective of SoftwareEngineering. That is, let's an objective look at whether object-oriented domain models mean very much with respect to how we accomplish our jobs, and the impact on the quality and timeliness of the fruits of our labor.

First, let's make some postulations about how we can discuss domain models in an objective, quantitative way.

What are the quantitative measures that can be applied to a given software system with respect to construction and operation? I posit the following:

Caveat: The following measures deal with commercial software systems (e.g. any software that is sold, or is used in the pursuit of making money). Some of these can be applied to all software projects, including freely available software. But let's face it, if your software does not generate revenue, then you are coding for kicks. Then you can make all of the intellectual pleasures be your guiding parameters. I, however, do this for money and I must make sure that I serve the right master. But that doesn't mean I can't get my intellectual jollies as well. ;)

Construction Quantities:

Completeness (Scope) - Does the system satisfy all of the requirements?
Quality - How well does the system pass unit and QA tests?
Schedule (Cost & Time) - How much money did it cost to make the software and did we hit the market window?
Correctness - (Discussed later)
Adaptability - (Discussed later)
Maintainability - (Discussed later)

Operation Quantities:

Performance - Is the system processing fast enough? Quality - Once in production, how many errors crop up? Cost-of-ownership - How much does it cost to buy, install and operate? Scalability - How much load can it handle? Can I make the system handle more load easily? Maintainability - Can the operations or customer staff deal with problems after deployment?

Process Model and the Data Model

In my humble opinion, all SoftwareEngineering comes down to one thing: dealing with SpaceTimeProblems?. The value of any technique or technology is measured by how well is enables software engineers to deal with SpaceTimeProblems?. In all software systems, there is process and data. They form a duality: you can't have process without data and you can't have data without process. A process without data to manipulate or calculate has no value. Data that has no process to manipulate had no value.

When I do software engineering, I always look at the system in terms of a process model and a data model. The problems I deal with when they come together are SpaceTimeProblems?. I especially do this in concurrent distributed systems. So when I think about TheValueOfDomainModels, I need to know whether they help me deal with SpaceTimeProblems? and I measure the efficacy of this in terms of the quality mentioned above.

Also, when I do software engineering, again especially in distributed systems, I need to play a game. I call it TheResourceGame?. As a software engineer or "architect", it is your responsibility to make sure that you have played TheResourceGame? well. There are 4 resources that you need to worry about. CPU, I/O, Network and Storage (both memory and disk). All of these resources are excruciatingly quantifyable.

It is my belief that ObjectOrientation attempts to try to unify the process model with the data model. Sort of the Grand Unified theory of software. I think that this leads to a bunch of confusion and suffering. ObjectOrientedProgrammingLanguages were designed to provide for the encapsulation of data within the wrapping of process. Ergo .. the Object. Why did they do this? Perhaps merely for intellectual jollies, but I believe that this tactic was build to improve the resultant Construction Quantities over other software manifestation technologies (such as assembly, procedural languages, functional programming languages, etc). The BIG QUESTION is: Is there any scientific proof of this hypothesis? I personally haven't seen any. Maybe I'm just dumb or I just missed that paper at OOPSLA. I mean, I have seen studies that validate the PairProgramming hypothesis.

To be OO, I have seen professed that you need three qualities: Encapsulation, Inheritance and Polymorphism. Further, it is supposed that when you have these qualities in a programming language or system, you increase the amount of "Reusability" of the code base. I have seen a plethora of statements that claim that a system achieved 80% reusability (or some such fiddle-faddle). I have further read that "Inheritance is the cornerstone of reusability". I think that is a load of crap. I posit that "Communication is the cornerstone of reusability." If you don't know about it and understand it, you ain't gonna use it. And "reusability", in my opinion, has nothing to do with being OO. I can't tell you how many projects I've seen go belly up because they were more interested in designing and implementing a wonderful class hierarchy. If you link in a third-party library or load a third-party jar file, then you have reusabilty.

All this talk about OO is nice and all, but does any of that help me as a professional software engineer engaged in solving SpaceTimeProblems? and playing TheResourceGame? as an architect? Ummmm ... not really. Then what is the value of OO in general, let alone TheValueOfDomainModels? Let's remember what software exists to do (in its most base form). And that is to allow business to MAKE MORE MONEY by allowing their businesses to be more efficient. It also exists to allow otherwise impossible computing tasks possible (like guidance systems and robots) but that is a digression to my point. If one was to use the MAKE MORE MONEY criteria to measure the success of any particular software technology, then COBOL on IBM Mainframes win, hands down with no discussion ... period. But as we have seen, the speed of change (physics propeller-heads call this acceleration) of business problem domains has been increasing at some non-linear rate. What does this mean to the software professional? Well, in a nut-shell, it means that the pressure is ON. Good programmers, in my experience, are not necessarily any faster programming in one language or another. So I don't think that OO programming languages give any real advantage here. But, the problem is, quite curiously, understanding the problem. This problem manifests itself, not in the exposition of the problem space itself, but the COMMUNICATION of the problem. Does everyone really understand the problem to be solved and the role of the software system in that solution? In my experience, this is the big time sink (and time=money) is in making sure that all the software folk know what they are doing. And, in my humble opinion, is where we can start to see some quantifiable value in DomainModels. Now I would like to talk about the other Construction Quantities I promised to talk about. It is in these quantities that we might be able to find some value in DomainModels?.

Correctness: How well does the software solve the problems it was built to solve? In other words, is the software solving the right problem?

Adaptability: How well can we change the software to adapt to changing requirements while preserving the original schedule? In other words, can we change our minds mid-stream and still make the deadline and therefore the market window?

Maintainability: How well can we perform surgery on the software in order to repair defects? And, more to the point, how well and how fast can programmers other than the original author(s) perform surgery on the software in order to repair defects?

These quantities directly correlate to how well the problem is communicated and understood. In a OO language, the manifestation of the Conceptual Model, Logical and Implementation (or Physical) model should be able to tell you, in part, how well the communication has gone. For example, if you are building a securities trading system and you don't have a "Security" modelled, then you might have a problem. The value of a DomainModel can be expressed as a function of at least the above mentioned quantities. However, we cannot get an intrinsic value of DomainModels? by comparing systems that use domain models, but only in comparison with systems that do not necessarily use a domain model. To do that, you need some objective measures. I'd need to think really hard about how to do that. But if we do the comparison between domain models, then we need some objective measurements on the domain itself. This is due to the fact that problem domains can vary wildly; I mean, how do you compare apples and oranges. These objective measurements and comparisons between problem domains ARE the realm of SoftwareEngineering and the domain of SpaceTimeProblems? and TheResourceGame?.

So how does one measure the above quantities. Well, it's done by measuring dollar flow rates. It's an economic problem. If we would like to debate the ethereal intellectual qualities of DomainModels?, then we will never get anywhere.

-- JeffSimpson

Would it be worth creating a wiki for DomainModelling, focusing on techniques to move from concepts in the problem domain to those mapped in an object graph? There seems to be various styles and techniques that might be worth documenting. As an example, Craig Larman recommends not using inheritance structures in a domain model. However, for those new to domain modelling this sometimes poses problems. When a domain concept clearly falls within a taxonomical type hierarchy, how do you show it?

--NickRobinson