On 11/01/2011 04:41 PM, Markus Krötzsch wrote: > On 31/10/11 19:17, Samuel Lampa wrote: >> The only little caution I'd like to make, is that the decision keeping >> data objects atomic makes them follow the Anemic Model antipattern [1] a >> bit. But that is of course a question about model design approach >> overall, and not this specific case only - that is, whether one wants to >> follow Domain Driven Design patterns [2] or not. > > Reading [1], I think there is a misunderstanding in the way you seem to > apply this text to SMW (probably due to my ill-chosen examples of > property and wiki page out of all dataitems). The text states that > domain specific behaviour of domain objects should be implemented in the > classes that represent the objects. This is what we do. Our domain > objects are strings, numbers, geographic coordinates. This is the very > data that we want to manage in SMW, it just happens to be rather atomic, > simple and (application) domain independent. Note that we do not > artificially try to abstract or simplify the objects to get this > representation -- these simple concepts are really the kinds of things > that SMW users deal with. > > Yet we include all related code into the objects whenever such code is > needed. For example, you can have a look at SMWDITime to see a lot of > calendar/date specific code. We could also have similar methods for > strings (e.g., substring computation) and for numbers (e.g., for > rounding) but this was not necessary so far. Our data items do not > include parsing/rendering functions that are specific to syntactic > formats like HTML, wikitext, JSON, RDF, SQL, ... which I think is good > (and established) design (you don't mix all parsing/serialisation code > into one class).
Thanks for the clarification! I was obviously a bit quick to make an overall judgement, without studying other parts of the SMW code. What you describe sounds fine. I indeed agree with separation of concerns. Just as a sidenote I know that one very successful approach is to have "domain controller classes", for the different "domains" (or more properly "subdomains") or concerns, that aggregates and concerts all activities belonging to each concern, whether that be through rich domain objects, service objects, and any combination of those, but most importantly that all this concentrated and managed from the "domain controller object" (think "SMWDisplayDomain", "SMWExportDomain" etc ...). ... so, I'm indeed not a proponent of gather every possibly related functionality in normal domain objects. :) > The big fallacy of [1] is to suggest that "object code" must always be > much larger that "application/service code". If taken too serious, this > could lead to a design that tries to merge all functionality into a few > objects, thus contradicting the fundamental programming paradigm of > separation of concerns. For example, SMW used to have HTML rendering and > RDF serialisation methods for data in a single class, in spite of the > fact that these functions are not at all related but merely work on the > same input data. > > This earlier design of SMW has also undermined another important idea of > OO design: the definition of clear interfaces with limited visibility. > The code for parsing, rendering, representation and serialisation used > to have full access to all internal fields of the objects. Before the > introduction of data items, it was quite unclear for some objects where > the data is actually stored (there were multiple redundant/overlapping > internal representations, sometimes optional, to reflect the internal > state of the object; all code would directly read/write to any of the > members). True. Next sidenote, that the "Domain controller object" approach I'm familiar with, also makes it easy to add "facade" objects, specific to the different concerns, which manage visibility and the like, to all functionality related to that particular domain. > A third main reason for keeping single objects small is that SMW is > meant to be extendible. If each new storage backend or display format > would rely on adding code to domain object classes, it would be very > hard to extend the system. Good point too. > Overall, I still think that SMW follows most of the guidelines of > Domain-Driven Design but for a domain (data management) that is very > different of what the author of [1] had in mind. Indeed. > Another special > observation about SMW is that most of our "business logic" is related to > parsing and serialisation -- tasks that should normally be separated > from the data that they work on. An interesting observation ... got to think a bit on that :) > But maybe one has to take a step back > and ask what the "domain layer" and "application layer" in SMW really > are to compare it to the DDD idea. :-) Yeah, an interesting thing to ponder as well! :) (Sidenote no. 3 is that the "domain controller object" approach simply has the application layer in the domain controller objects ... thus tying together application and domain layer very closely, eventhough a clear separation is still maintained (application logiv in the domain controllers, domain logic in the other domain objects). ... and then the corresponding facade objects provide the presentation/API level logic, to which UI code and other extensions can talk.) All in all: Thanks for an interesting and clarifying elaboration of the design choices! To the best of my judgement it sounds well thought-through and reasonable. My sidenotes are just my spontaneous reflections that I couldn't resist to add, since I find that the "domain controller" approach really fills a gap in the land of DDD, on how to actually implement the separation of concerns, as well as the application layer, in practice. Cheers // samuel ------------------------------------------------------------------------------ RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Semediawiki-devel mailing list Semediawiki-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/semediawiki-devel
