I was reviewing some threads on Stack Overflow and started asking myself how I would design my classes and relationships to create such a system.

My Goal -

I want to build a review system like the Stack Exchange review system.

Let's take a look at how the review system works on Stack Exchange. I will only refer to the Suggested Edits functionality to keep it simple.

  1. Un-experienced user (less than 2000 rep) edits someone post
  2. Add an entry to the "review" system tagged 'suggested-edit'
  3. Experienced user (more than 2000 rep) can review "suggested edits" one by one

As an experienced user I can:

  • See the diff between the original content and the edited content
  • Approve the edit
  • Reject the edit
  • Improve the edit
  • Skip to the next review

Final note about other review types. We could imagine "tagging" the reviews with the corresponding types since the actions are the same.


I would start with a Review model. We could have one sub-class for each review type, allowing custom attributes and methods for each type in the future.


class Review
class Review::SuggestedEdit < Review
class Review::FirstPost     < Review
class Review::LateAnswer    < Review
class Review::LowQuality    < Review

A Review object would have 2 references:

  • Original Content
  • Edited Content
  1. Replace original content by edited content.
  2. Mark the review as approved.
  3. Move to the next review.
  1. Log the reason for rejection.
  2. Mark the review as rejected.
  3. Move to the next review.
  1. Directly edit edited content.
  2. Approve.
  3. (We could imaging creating a new Review for this improvement.)
  4. Move to the next review.
  1. Move to the next review.

How should I structure my classes in order to build such a review system?

  • 1
    check this out : discourse.org
    – Chedy2149
    Aug 18, 2013 at 8:27
  • You mean I should ask the question on discourse ? Aug 19, 2013 at 5:43
  • No I'm suggesting to use discourse instead of building something from scratch.
    – Chedy2149
    Aug 19, 2013 at 8:21
  • Thanks but I may want to build a StackExchange like-review system for something else than Questions/Answers. For example, if my business deals with "text translations", I may want my authors' translations to be reviewed by my community. This tool would have to be build internally. Aug 19, 2013 at 9:15
  • Beside, the question here is how should I structure my classes, not what tools can I use. Aug 20, 2013 at 7:05

2 Answers 2


This sounds like a potentially good fit for for a CQRS "architecture" (http://martinfowler.com/bliki/CQRS.html) with Event Sourcing. What your system cares about is not so much the domain model state but the changes to it - instead of maintaining tables holding the current state of each entity, changes can be modelled and persisted as events triggered by commands from the UI.

The actual state of the system is discovered by playing back all the events, so you can reject edits and easily revert by skipping them. Because of this, though, queries may become slow. However, as you already have event sourcing, you can maintain query data as pre calculated, de-normalised sets. These can be stored in dedicated tables, in cache memory, or as flat files.

  • Interesting, was not aware of this design pattern, thank you for teaching me :) Dec 9, 2013 at 6:57

I'm not sure how I would model this exactly, but what you are describing is very much like a version control system. Like Svn for a VCS or git for a Distributed VCS

The ability to track changes, view/visualise or edit diffs, log, merge, revert, tag/label is all there and is particularly good with text diffs.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.