Social Networking Patterns

I've had some interesting reaction to my post on Social Networking, that I wrote basically to apologize for making people wasting their time. After concluding that social networking is probably some sophisticated IT warfare weapon developed to harm productivity of the western countries, I've had an interesting conversation with Giulio Cesare Solaroli, the mind behind the Clipperz online password manager, about the fact that as platforms are becoming more open, intercepting users behavioral pattern is a key concern for any social web application.

I am not quite sure if the notion of pattern fits exactly the situation, but I blogged about it before, and then found site WikiPatterns which published a consistent catalog of behavioral patterns, that reflect themselves in the shape if the information. There are more than 50 patterns and antipatterns just for a Wiki, in a scenario with some evident boundaries, like

• People are told to go to a wiki
  
• The people working on a wiki are already some kind of group (development team, company, etc.)
  
• They should share a common goal
  

A social networking tool such as LinkedIn, Naymz or Spock, has a similar high-level goal which is provide some form of valuable knowledge as a result of individual contributions by the user, but is far more open. Nobody asks you to go on a platform (well, … somebody invites you…), you're not necessarily part of the same group, and there is no such thing as "the common goal". I've asked myself "why do I keep my LinkedIn page updated?", and here are the answers.

1. I like learning how a new tool works
   
2. It's useful for my marketing as a freelance
   
3. It's useful for my job, cause Web 2.0 and the like are part of my consulting portfolio
   
4. I can't stand fake or incomplete information
   
5. I hate writing CVs and LinkedIn looks like the right place to write information only once
   
6. Vanity
   

There are probably some more reasons, but here we are talking only about the relationship between me and the tool. For some of my friends reasons are completely different, and some other are not on linked in and they're not interested to move in. But the tool is a networking platform, and this means that a lot more variables and scenarios are possible. I'll drop down something.

1. What if somebody wants to connect with you and you don't know him?
   
2. What if somebody wants to connect with you and you don't remember him?
   
3. What if a friend connects with you but not in the right position?
   
4. What if a friend endorses you for the wrong position?
   
5. What if somebody asks for an endorsement?
   
6. What if somebody endorses you, but you have no direct experience about the way he/she works?
   

Ok, one can develop some sort of "SocialNetiquette", but thinking about it is some sort of undesired side effect (it wastes brain cycles). But the key point, at least for me, is that I couldn't make up a consistent behavior. In other words, I don't give the same answer to the same question – after all, I am a consultant, so "It depends" is my mantra… As a result, some of my connection are strong, related to people I know well, that I've worked with and so on, but some are not. Are we abusing the tool? Or we're still using the tool the way it was intended. Or… does this question actually make sense?

A key argument about all Web 2.0 technologies is that providing strict rules about the way a tool is used is a losing approach. Tools should instead "follow" users needs and ideas and transform themselves into something that wasn't exactly planned in the beginning. It's sort of seeding something and then taking care of what's growing. More realistically, Linkedin can't ban users because they connected without knowing each other well enough (would you like to be interviewed by linkedIn police about your connections?), so its body of knowledge is made up of contributors which are not providing a consistent behavior (as individuals and as a crowd), which are posting incomplete and sometimes wrong information. Yet it works.

I still have the feeling of being part of a big experiment, but according to the Hitchhikers' guide to the galaxy, this does not necessarily mean that I am stupid.

Tags: Social networking, web 2.0

Java IDE Day

Just a quick info post to inform about the Java IDE Day, which will be free, in Genova - March 10th 2008 and Rome - March 12th 2008 jointly organized by Genova Java Users Group and Rome Java Users Group. For more information, please follow this link. I can't say if I'll join or not, yet, but the panel seems pretty interesting anyway.

Tags: events, Java, Italy

Social Networking Bloat?

This morning I received a mail containing an invitation to join a friend on Naymz social networking platform. I am quite interested in the topic (as as freelance, LinkedIn is one of my primary marketing tools) and trust the sender also as source of good hints, so – even if I am already registered on LinkedIn, Plaxo, Experteer, Facebook and Spock, I promptly joined in.

Every social networking has its value tightly related to the number of users. I've the feeling that the value provided by those tools is somewhat marginal compared to the fact that "you've got to be where the others are", sort of teenage grouping patterns transferred in a business relations territory. Well, Naymz folks got it pretty clear, so they included the possibility to spread the invitation in the fastest possible way, by importing LinkedIn connections and transforming them into invitations. Plaxo had a similar strategy, but was somehow more under control. Anyway, the result was something like an infection spread: Naymz sent invitations to around 60 people (I avoided those I didn't want to disturb, or the like), started sending me an e-mail every time one of my contacts took a look on my profile, and quite a few people joined my network pretty quickly. Then I started peeking to check if my ranking (a way to affect videogames addicted people more effectively) was increasing. I thought about the overall time this activity was dragging from more productive ones, and started to feel somewhat guilty. Maybe not all of my friends were really on "productive stuff" but the amount of overall time (counting a couple of minutes or more for contact) put on this unpredictable and not urgent at all activity was surprising, and made me use some more time thinking about what had just happened.

Yet another social networking tool?

SN is sort of hot topic nowadays and every internet company wants to become rich as Facebook folks did, even if nobody knows where the value comes from. Well… value comes from the critical mass, so Naymz and Plaxo piggybacked on existing networks such as LinkedIn (which in turn imports Google Mail connections). Unfortunately, being there is not the same thing as being there and there and there, and also there. Cause nobody could spend so much of his time just checking different SN tools, and because the ROI of your time decreases every other SN tool you use.

The funny thing is that differences in those tools are getting thinner and thinner, maybe pushing for a specialization of tools for specific purposes, more often generating huge areas of overlapping. Naymz is for reputable professional networking and has some sort of ranking, based on reliability of the information provided and opinions about you. Unlike Linkedin, connections are not shown, so you can't use Naymz to discover somebody's else's connections and your reputation is the sum of private opinions of your network.

What I've found annoying is that the "say something about you" or "endorse your connection" introduces data duplication with LinkedIn (which in turn has duplicated information with my Experteer profile), turning profile management into a complex activity on behalf of the user (something which is deeply wrong for my principles). I guess the next to come is just a Social Networking Management Console, allowing user to control every platform from a single access point. But this is also what every SN Service Provider is already trying to do, so probably my Darwinian expectations of natural selection are going to be unsatisfied.

Social Networking patterns

A couple of days ago I stepped on Plaxo, and read a blog entry by Andrey Golub which was linking to another article, by Mark Cummuta. It was interesting because it pointed out that SN tools are not used at all in the same way. Despite some advices in the main screen, some folks use LinkedIn, to know people instead that linking to people they already know. Somebody is interested more in the number of connection, than on the trust you can put on those connections. Controlling the way your users use a SN system is a difficult task, which has nothing to do anymore with coding. It's a mixture of social and behavioral sciences together with user interface design (because allow and make it easy are different things here). But you've got to be careful not to decrease the value of the platform you're on, or – worse – to make it annoying. I wonder how many of those SN service provider are approaching the problem from this perspective. But today I really felt like I was part of some worldwide social experiment.

Tags: Social Networking, Web 2.0

Domain Driven Design in Java: Repositories and DAOs part 3

In the previous posts on the topic (part1 and part2) I've highlighted common characteristics and differences between the DAO and Repository patterns. In situations where the modeled domain is simple, a traditional DAO approach (backed up by frameworks) is probably good enough. If your domain is more complex, or if complexity is growing, differences between DAOs and Repositories become more important.

• A larger domain calls for a higher level of abstraction: Repositories could help implementing new functionalities because they hide more of the underlying layers.
  
• Complex systems cannot always be modeled with a one-database strategy: whether a Model-DAO-DB model makes sense for most of the normal application, this is a "reasonable assumption". There are anyway situation where a Repository should hide more complexity than a simple database call.
  
• Simply stating that "access to the database should always happen through Aggregate Roots" could be not enough to preserve your architecture's integrity.
  

So, given that DAOs come almost for free in a Spring plus Hibernate environment, the question now is understand if we need something more than that. To put in another way, if DAOs drawbacks (tied to the database representation, more data-oriented than model-oriented, not enforcing access only via aggregates but a one-dao-per-entity approach) are something we can live with or a call for a targeted solution. To be honest, there's also one limitation with DAOs, which is related to the layer they belong to (the persistence layer or whatever you want to call it), while it is been said that Repositories belong to the domain layer. This is a controversial issue… I'll leave it for later.

Ok, the proposed approach with Repositories and DAOs is to have Repositories on top of the persistence layer, and have Repositories call specific DAOs. Something like

Which is quite similar to Debasish's proposal on this post. Repositories expose a more business-oriented interface, compared to DAOs and could enforce access only via Aggregate Roots. Repositories should belong to the domain layer, for a couple of reasons:

• Data access isn't conceptually a dirty thing. A pure OOP approach made up by only traversing associations (and have am ORM framework doing the dirty job behind the scenes) could impact performance.
  
• They should not be tied to any implementation issue. Repositories expose abstract store and retrieval operations but no implementation details.
  
• They could contain business-oriented logic related to searches: getUnreconciledOperations(BankAccount ba) could be used instead of getOperationByAccountAndDateRange(BankAccount ba, Date from, Date to).
  

Personally, I like the proposed solution, which is also implemented via Spring dependency Injection. But I can't help feeling somewhat weak when it comes to explain the advantages. I mean "speaking the language of the domain" is a good thing to me. But is quite far to be a compelling principle when it comes to "sell" an architecture proposal to a team. They have established practices with DAOs, and we're suggesting to add another layer on top of it. If you are lucky enough to have a common understanding of DDD principles and values in your team, then you're probably in a sort of positive loop, and one DDD practice enforces another one and the whole result is a good thing. If this is not the case, this approach might look like it provides marginal value at the price of an increased complexity.

One more thing that could get in the way is code-generation. It is often possible to have some sort of code generation applied to DAOs. Such DAOs are good but flat, and in many cases they call for a business-oriented refinement, while hand-coded DAOs are generally somewhere in the middle. But if adding a Repository layer breaks the code-generation cycle, it could (one more time) be not worth the effort.

Tags: DDD, Design patterns, Hibernate, Java, Spring

Domain Driven Design in Java: Repositories and DAOs part 2

In my previous post I've scratched the surface of the Repositores vs DAO debate, showing that there are points in common but also some differences. Now it's time to become a little less technology agnostic and try to solve the problem in a common java environment such as Spring plus Hibernate.

The original specification was totally technology agnostic – the only reference in the DDD book was to entity beans (which sound so naïve nowadays) – but there were some recommendations, quoting Eric Evans:

"Before implementing something like a repository, you need to think carefully about the infrastructure you are committed to, specially any architectural frameworks"

Ore the more concise:

"In general, don't fight your frameworks"

Which sounds as pragmatic as one would expect. Ok, we have frameworks. We have Hibernate that provides a convenient abstraction for database access, and we have Spring that suggest a mainstream way to deal with persistence through DAOs and the xxxDAOSupport classes. Do we still need repositories? In many cases the DAO approach could be quite sufficient, even if some attention must be put when dealing with Aggregate Roots.

Accessing persistence only through aggregates

One of the strongest recommendations of DDD is to partition the domain model, to highlight Aggregate Roots and related Entities and Value Objects. As a result you could conceptually draw regions on the class diagram, with some properties:

• There's only one Aggregate Root per region
  
• An Entity can belong to only one region
  
• Value objects can be used in different regions
  

Mapping the concepts to Hibernate, a Value Object can be more or less implemented as a Hibernate Custom Type, while there's no difference in the implementation for simple Entities or Aggregate root. Put in another way, Hibernate's view of the domain model is flatter than the one you can achieve by applying domain driven principles to modeling. Does this matter? It depends a lot on the complexity of the domain. When dealing with relations such as the classic Order – LineItem, applying strictly the "access the data only through the Aggregate Root" rule help solving a lot of complex situations. They're simply less complex. As the system grows, you have a view (I liked the regions on the class diagram) that helps keeping coherence of the system. It's probably overkill for small systems, but DDD is for managing complexity, and it helps. Moreover, this type of approach gives also a consistent way to deal with Hibernate's features like lazy-loading: associations crossing regions boundaries were forced to be lazy-loaded, while inside the regions one could apply eager-loading if needed. So it makes sense to have a centralized access point related to Aggregate Roots instead of generic entities. Still you can enforce this rule by using only one DAO per Aggregate Root, or go for the more radical approach proposed by Debasish Ghosh in his blog, which is to have a Repository Layer on top of DAOs.

Continues on part 3.

Tags: DDD, Design patterns, Hibernate, Java, Spring

Domain Driven Design in Java: Repositories and DAOs

I past the last days digging the net from some information about the implementation of the Repository pattern, as described in Domain Driven Design, in a typical java environment backed by frameworks like Hibernate and Spring.

It turned out that the situation is more complicated than I expected, and that pieces of information are scattered all around, mostly in newsgroups and blogs, so it took me a while to grasp the whole picture. Here is my summary.

The REPOSITORY specification

The original definition of the repository pattern, comes from Martin Fowler's Patterns of Enterprise Application Architecture, but the pattern itself is credited to Edward Hieatt and Rob Mee. The whole idea is to abstract access to the underlying database and provide the illusion of an in-memory collection of domain objects. Hmmm… sounds a lot like DAO to me. And also a bit like Hibernate's lazy-loading. In fact the two concepts of Repository and DAO, are quite similar: they're doing basically the same thing.

Repositories and DAOs

So the first question is "Are Repository and DAOs the same thing with a different name?". I am tempted to write "Yes!", and this will anyway be a legitimate answer in many cases ( some evidences can be found on the Spring Forum and on Christian Bauer's blog), but some differences in the way the two patterns are used were emerging there and there, so I kept on investigating. Going back to the source didn't help, cause both the original definitions are rather vague, at least in 2008 terms, and open to a wide range of implementation styles. So, even if the original definitions were largely overlapping, common habits in using the two patterns consolidated , making Repositories and DAOs two solution styles for approaching the same problem, with some small differences.

1. DAOs are strictly tied to the underlying representation on a DBMS. The original specification is more generic, allowing for file-based persistence and the like. But the vast majority of DAOs are pointing to a DBMS. Moreover, commonly used persistence frameworks, such as Hibernate help a lot in managing database portability, so this is a smaller issue nowadays, than it used to be. As a result the DAO concept eventually downsized, to a "database access point" while Repositories are still intended to be generic.
   
2. Repositories provide a more abstract view over the underlying data model, providing an interface strictly coherent with the domain. DAOs might be implemented basically in many ways, but frameworks and code generation tools tend to put the focus on the data structure rather than on the domain model. This is sometimes a tiny issue, sometimes just a matter of style, but in large systems can degenerate in a severe maintenance problem.
   
3. Repositories enforce access to the persistence layer on a one-repository-per-aggregate basis, while DAOs are normally developed one-per-entity or one-per-table. So, repositories are more tied to the DDD concept of Aggregate Root and have a different granularity than DAOs. This definitely makes the most significant difference.
   

Somehow, the differences above are just a matter of taste, except for point 3. So objections are valid and discussion may result endless. But for now I'll just say that the two patterns are doing basically the same thing, although with different styles. There are differences, especially if approaching the matter from a DDD angle. What's left to say is if those differences are enough to make a choice between one pattern and another, or eventually to choose both.

For a more complete perspective, please read also part 2 and part 3.

Tags: DDD, Design patterns, Hibernate, Java

Great presentation about Identity 2.0

It's not exactly fresh, 'cause it comes from the OSCON 2005 presentation, but the keynote about Identity 2.0 from Dick Hardt is definitely a good one.

Tags: Identity 2.0, Presentation