-
Notifications
You must be signed in to change notification settings - Fork 30
/
README
44 lines (40 loc) · 1.64 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
This is a thought experiment for how Raptor apps might be designed. The module
hierarchy is:
Routes
Injectables
.current_user
.post_params
Interactors
CreatePost
PostSaved
ValidationFailure
Models
User
AnonymousUser
Post
Records
User
Post
Responsibility breakdown:
- Routes are the same Raptor routes as ever. They can route out to different
actions/redirects based on the interactor's response.
- Injectables provide objects for Raptor's implicit DI. For example, the
`post_params` injectable does what it sounds like, so that
Interactors::CreatePost can take a `post_params` argument without worrying
about where it came from. These are class methods directly on the
Injectables module.
- Interactors contain the application's logic. They return (or raise)
response models that are usually defined directly in the interactor's class
(or maybe from a shared location if appropriate).
- Models wrap database records to provide simple mutations and data wrappers.
For example, Post#publish updates the published flag and saves. These
don't necessarily map to records one-to-one. For example, the AnonymousUser
model exists to avoid a nil current_user, and doesn't map to anything in
the database.
- Records are straight-up database records. No methods; just field
definitions.
This hierarchy doesn't correspond to the file layout. Instead, files are
grouped by topic. For example, posts.rb contains Interactors::CreatePost, the
post_params injectable, and the Post model. Modules in the system will be
reopened many times as code is loaded, giving us lasagna files instead of
ravioli files.