Hello Clojure people,

First up, apologies because this is going to be a long message. Howver, if 
you do have the time to read and respond, then I would be extremely 
grateful!

Recently I've decided to give Clojure a proper go. Over the past year or so 
I've paid it a bit of attention: I've read books all about how to use it 
and I've spent a bit of time working through tutorials to create little web 
apps and so on. I understand the language (although not to any great depth 
yet), but I'm still unsure about the best approaches to actually working 
with it.

I've got many years of OOP experience, and I'm a big fan of principles like 
SOLID and approaches like DDD. What I want to do now is, try and learn how 
to build well designed models using Clojure, while using best practices! 
I've started having a bit of a crack at it by building a simple app, but 
I'm finding myself trying to transfer a lot of my existing OOP techniques 
into Clojure. It's working, but I'm wandering if I'm overdoing it or 
perhaps just not doing things "the Clojure way".

So, my very first question is are there any good books or resources on 
modelling, application architecture or best practices, using Clojure?

Next up, maps vs records. I've read that the typical approach is to use 
maps until the design starts to solidify and then you can move to records. 
Is the the general attitude of Clojure developers or do some like to dive 
straight in with records?

The next question is encapsulation: I've taken the approach that I'm kind 
of using namespaces like classes. If I want to create customer entity I 
create a namespace for it, then add a "make" function to it which returns a 
map of the right "shape".  I'm then shying away from accessing the map 
directly, and rather doing it through other methods in the namespace which 
take the instance as a parameter. E.g.

(ns app.domain.customer)


(defn make [name, email]
  {:name name
   :email email})


(defn get-name [customer]
  (:name customer))

Is this a reasonable approach? If not, what might be a better one?

This leads on to safety and defensive programming. Using the approach 
above, how much "type safety" is required? Obviously, in any API which is 
going to be used by other programmers, you've got to handle bad inputs 
well. But what is the Clojure approach in the "domain model"? Coming from 
the DDD mindset, where models are designed to be un-breakable, part of me 
wants to use records for all entities and typehint for them everywhere. 
However, I wander if the Clojure way is more about rigorous testing to make 
sure the wrong values don't get put in in the first place? Also, what about 
libraries like https://github.com/Prismatic/schema, this could be used in 
:pre conditions to be more explicit, is that a common thing?

Next up, how far do you go with creating "types" vs using primitives? 
Again, referring back to DDD, both the email and the name in the example 
above are suitable candidates for value objects. In Clojure, would you 
consider hiding the data behind a set of specialised functions to create, 
access and use it? Or would you just pass the primitive 
string/map/vector/whatever about and work on it directly? Example:


; Given
(defn make-customer [name email]
 {:name name, :email email})
 
; Examples
 
(def customer1 (make-customer "Tom" "em...@address.com"))
 
; vs...
 
(defn make-name [name] name)
 
(defn make-email [email] email)
 
(def customer2
 (make-customer (make-name "Tom")
 (make-email "em...@address.com")))



I think that's all I want to ask about now. I do have other questions about 
dependency inversions, but I'll leave that for another time. If you've read 
this far then thank you very very much! Also,I know that no one really 
wants to just sit and read though random peoples code, but, if you are 
interested in my (very very early stages) experimental project, then I've 
put in on https://github.com/tomphp/clojure-cocktails - any comments, 
critiques, PRs or questions would be really great!

Thanks you so much for your times and I look forward to any thoughts or 
suggestions!
Tom

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to