This article is incomplete; it will be constantly in editing mode.
The seasoned developers know that it is not easy to conduct OOP. The process of domain model analysis is non-disciplined; it mainly relies on the intuition or the experience from the past--the pattern language. The OOD is great tool for implementing the 'Solution', not for simulating the real world. The pitfall of the OO developers is that they cry for the classes with that they can initiate their development, but there are no easy way to get them without vigorus up-front efforts to model the static class digaram. This practice is usually expensive. And the bad news is the output from this practice will be very volatile and it requires the high cost to change them later in the development phase. This fear of future change causes even more delay on this domain model analysis.
The reason why OOP becomes hard is because developers think that their class must somehow simulate the real world, and it is neither achievable goal nor worth it. We must shift our mindset from the simualation of reality to the application of the 'Solution'. The 'Solution' is the virtual entity and the ultimate outcome of given programming job. Once whatever the 'Solution' is defined, OO designers put the OOP tool into an action only to implement the 'Solution'. This 'Solution' first approach resembles the very purpose of the Use Case Dicipline; it will show the concrete class objects that is needed immediately.
This way developers will quickly get any classes that they can use in the very contained scope of functionalities. They are more likely the mechanical piece of the 'Solution', not the conceptual entity of the domain. The changes are minimal and manageable within the limit. But we still need domain entity for the better depiction of our 'Solution'. Can the business entity be so simple, yet adapt to the changes? This question leads us to the next subject--Agile Domain Modeling.
- Architect is Solution Engineer, not Software Engineer.
- What is exactly the 'Solution'?