The architecture of a large system should designed independent of the language in which you're working You should strive to identify the architecture styles you need for your problem domain, and then intelligently compose them with connectors that help fulfill your nonfunctional requirements/guarantees.
I doubt you're in a problem space where something like CQRS is needed, but you might compose something like MVC with DDS, and use complex event processing where necessary. Doing so will create an asynchronous, data-centric architecture, which can also have the ability to make QoS guarantees. As a bonus, it can also operate somewhat autonomously (if your run your system runtime metrics through the CEP piece). Here's a naive drawing: http://www.pauldee.org/example_arch.png It's not a component-connector, UML, or deployment diagram, but a quick sketch that borrows from all of them. The CEP work is very fitting for Clojure (Clojure parallelism + Esper + WabbitMQ library OR ). Note that in this architecture (and in most scalable, asynchronous architectures), the data will always be "Good Enough." You'll continually merge the approximations of some pieces of data with the actual data once it has been calculated. See Nathan Marz's "Secrets of Building Real Time Big Data Systems" -> http://www.slideshare.net/nathanmarz/the-secrets-of-building-realtime-big-data-systems The entire system could be done (and easily scale) in Clojure, but your traditional control layer/logic and view get exceptionally thin when you're working with the styles listed above, so it's best to write those in whatever you're most comfortable with (ie: what you can develop the fastest and what you can deploy and scale the easiest). Hope this helps, Paul http://www.pauldee.org/blog References: MVC - http://en.wikipedia.org/wiki/Model_View_Controller DDS - http://en.wikipedia.org/wiki/Data_Distribution_Service Clojure and Esper - http://static.intelie.com.br/qconsp2010/presentation.html Stream Processing (if you don't need CEP, but still want asynch streams) - https://github.com/jduey/conduit On May 26, 10:05 am, Max Weber <mm.we...@web.de> wrote: > Hi, > > imaging you could do a software project from scratch and Clojure is the main > programming language. What architecture would you choose? Of course it > depends, so here are some requirements and basic conditions: > > - Let's assume that we are building a web application for some social > media stuff > - So it has to handle a lot of data > - And it has to scale (there are a lot more read than write operations) > - Your data store is a NoSQL document database (e.g. MongoDB) > - Your deployment environment is cloud based (e.g. EC2). > - It should be an architecture which fits the functional programming > paradigma: side effects should be rare and controllable > - The application should be extendable and maintainable > > It is obvious that an application cannot been done which fulfills all the > criteria mentioned above one hundred percent. However you may get very close > to one hundred percent for some of the points. > > At the moment I would say that CQRS <http://vimeo.com/13852695> is the most > promising architectural pattern to do scalable, maintainable and extendable > web applications. Nevertheless I've a very hard time to adapt the common > practices of a CQRS application to the "functional world". Most of the CQRS > stuff today comes from an object oriented world, particularly there are a > lot of .Net projects <http://abdullin.com/cqrs/>. There is also a CQRS > Framework for Java named Axon <http://code.google.com/p/axonframework/>. > > Regrettably, there are not much writings about what architecture you should > use, if you are working with a functional programming language in the > context mentioned above. May be I just not find the right websites or books. > So here is my initial question again: What architecture would you choose? > > Best regards > > Max -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
