3 ms·
This whole separation of UI and domain is the kind of Ivory Tower academic nonsense perpetuated by the DDD folks and many, many others. Nowhere is this virulen
by cletus 16y ago
This whole separation of UI and domain is the kind of Ivory Tower academic nonsense perpetuated by the DDD folks and many, many others.
Nowhere is this virulent plague more endemic than in the Java world. As the joke goes, the Java programmer's response to any problem is to add just one more layer of abstraction.
And I say this as a Java programmer of some 10+ years experience so please don't take it as mindless Java bashing.
As Joel (the classic Joel of old) would say: all abstractions are leaky. To add my own editorial: the less hand-wringing and self-flagellation about the purity of the uberlanguage, uberframework or uberarchitecture, the better.
- extension 16y agoModel-UI separation is a pretty basic principle that decent programmers put into practice every day. I find it tends to aid the design process rather than obstruct it.
- stcredzero 16y agoSeparating the domain from the UI is just common sense and good business practice. Having the two melded is probably the most common way for companies to get stuck using an old application. Their business logic (the real value) is stuck in a glob of UI outdated code (which no one cares about anymore). I say this as a Smalltalk programmer of 10+ years experience. Unfortunately, it's often been the worst Smalltalk apps that have had the longest life. In those cases, it's just too horrible to migrate to a different environment, and the rate of change in the current application makes the opportunity cost of freezing ongoing development too painful. The result is often one or two failed Java projects seeking to replace the Smalltalk app, which continues to creak along beyond all expectations. Often, the apps with the good architectures got replaced quickly. I think a lot of that could be fixed with automated translation to Groovy and some custom UI frameworks.