I think I've not got a much better idea of "data as the API" concept. What
I'm still wandering is where do you do the validation of the data. For
example, say a customer has a name, email and favourite colour. This could
be represented as a map like so:
{:name "Tom", :email "t...@whatever.com", :fav-colour :blue}
So I'm guessing that an add customer usecase would be implemented through a
function like so:
(defn add-customer [customer]
; ...
)
The system has rules which state that a customer *must* have an email
address and a name, fav colour is option though. My mind then says that,
because add-customer is an API call (as in someone implementing a gui will
want to make call to this function), then this
should perform some error checking that name and email exist in the map.
Reasonable?
Let's also say that maybe there's a *send-message* function, which takes a
customer and a record, and sends the customer a message. This function is
assumed to never be needed to be called externally from other functions in
the system, so at this point do we skip the customer map validation, and
assume that the API functions will protect against invalid customer maps.
Example:
(defn send-message [customer message]
(send-email (:email customer) message)) ; no error checking because
called from internal functions only
(defn add-customer [customer]
(when (customer-is-valid customer) ; error checking because likely to be
called externally
(add-to-database customer)
(send-message customer "Welcome")))
Does that seem reasonable? (I hope I'm making sense!?)
Also, what's the attitude towards adding entries into the data which are no
expected, for example if I define my customer map with an :age. Is it the
general attitude that adding an unknown field should cause an error, or
should it just be accepted? (I'm guessing this may be a more application
specific answer).
@Jirka: I'm afraid I don't have any answers to your questions (hopefully
others will) but I very much enjoyed reading the material you referenced.
Thanks for the post!
On Thursday, 16 October 2014 22:19:32 UTC+1, Tom Oram wrote:
>
> 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.
