You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
<imgsrc="/book/images/apwp_aa01.png" alt="a recap of all the layers + parts of our architecture" max-height="60%">
63
64
<figcaption>Here’s a recap of all the layers + parts of our architecture</figcaption>
64
65
</figure>
65
66
</a></p>
66
-
<p>I remember having to make a simple change to an app that the buying team at
67
-
MADE uses. We needed to record an extra piece of information for each shipment,
68
-
an optional “delay” field to be used in some ETA calculations. This is a nice
69
-
illustration of a trip all the way through the stack, because things have to
70
-
change all the way from the frontend/UI, all the way down to the database.</p>
67
+
<p>So. Once upon a time, early in my time at MADE, I remember having to make a
68
+
simple change to an app that the buying team uses. We needed to record an extra
69
+
piece of information for each shipment, an optional “delay” field to be used in
70
+
some ETA calculations. This is a nice illustration of a trip all the way
71
+
through the stack, because things have to change all the way from the
72
+
frontend/UI, all the way down to the database.</p>
71
73
<p>If you’re using a framework like Django, you might be used to thinking of a
72
74
change like this, in a perfect world, as a change you can make to just <strong>one</strong> file.
73
-
We change <code>models.py</code>, and then our<code>ModelForm</code> will be updated automatically,
74
-
and maybe even the frontend, if we’re using the form’s autogenerated HTML, will
75
-
“just work” too. That’s one of the reasons that Django is so good as a rapid
76
-
application development framework; by closely coupling its various parts, it
77
-
saves you a lot of messing about with database tables, html forms, validation,
78
-
and so on. And if those are the main things you spend your time on, then Django
79
-
is going to save you a lot of time.</p>
75
+
You would change <code>models.py</code>, and then your<code>ModelForm</code> will be updated automatically,
76
+
and maybe even the frontend will “just work” too, if you’re using the form’s
77
+
autogenerated HTML. That’s one of the reasons that Django is so good as a
78
+
rapid application development framework: by closely coupling its various parts,
79
+
it saves you a lot of messing about with database tables, html forms,
80
+
validation, and so on. And if those are the main things you spend your time on,
81
+
then Django is going to save you a lot of time.</p>
80
82
<p>But in our world (at least in theory <ahref="#in_theory">*</a>),
81
-
database tables and html forms are not where we spend our time. Instead, we
82
-
optimise for making it as easy as possible to capture and understand business
83
-
logic, and as a result we want to <em>decouple</em> things.</p>
84
-
<p>What does it cost? Well, let’s take a trip through each file I had to change,
83
+
database tables and html forms are <em>not</em> where we spend our time. Instead, we
84
+
want to optimise for capturing and understand business logic, and as a
85
+
result we want to <em>decouple</em> things.</p>
86
+
<p>What does it cost? Well, let’s take a trip through each file I had to touch,
85
87
when I was making my <em>very minor</em> change to the data model in our app.</p>
86
-
<ul>
87
-
<li>I started off with editing a selenium test of the frontend, plus a javascript
88
+
<olstart="0"><li>
89
+
I started off with editing a selenium test of the frontend, plus a javascript
88
90
frontend test, plus the frontend javascript itself, plus an html template.
89
-
That’s four files already, but they’re not strictly relevant to the patterns
90
-
and layers whose cost I want to account for, so I’m going to say they don’t
91
-
count. Don’t worry; there’s plenty more to come.</li>
92
-
</ul>
91
+
That's four files already, but they're not strictly relevant to the patterns
92
+
and layers whose cost I want to account for, so I'm going to say they don't
93
+
count. If you think I'm cheating, don't worry; there's plenty more to come.
94
+
</li></ol>
95
+
93
96
<p>So:</p>
94
97
<ol>
95
-
<li>An <strong>end-to-end / API test</strong> for the create and edit commands for the objects in question.</li>
96
-
<li>The <strong>Command classes</strong> that capture various<ahref="https://www.cosmicpython.com/book/chapter_10_commands.html">write interactions</a> a user can have
98
+
<li>An <strong>end-to-end / API test</strong> for the create and edit use cases for the objects in question.</li>
99
+
<li>The <strong>Command classes</strong> that capture those<ahref="/book/chapter_10_commands.html">write interactions</a> a user can have
97
100
with this model.</li>
98
-
<li>The <strong>command schema</strong> which we use to <ahref="https://www.cosmicpython.com/book/appendix_validation.html">validate incoming requests</a>.</li>
99
-
<li>The <strong>service-layer tests</strong> which instantiate those commands to test their
101
+
<li>The <strong>Command schema</strong> which we use to <ahref="/book/appendix_validation.html">validate incoming requests</a>.</li>
102
+
<li>The <strong>Service-Layer tests</strong> which instantiates those commands to test their
100
103
handlers</li>
101
-
<li>The <strong>handlers at the service-layer</strong> that orchestrate these use cases.</li>
102
-
<li>The <strong>domain model tests</strong> that were affected. Although <ahref="https://www.cosmicpython.com/book/chapter_05_high_gear_low_gear.html">not every domain model
103
-
needs low-level unit tests as well as service-layer tests</a>, so if I was being indulgent I might
<imgsrc="/book/images/apwp_aa01.png"alt="a recap of all the layers + parts of our architecture"max-height="60%">
18
20
<figcaption>Here's a recap of all the layers + parts of our architecture</figcaption>
19
21
</figure>
20
22
</a>
21
23
22
-
I remember having to make a simple change to an app that the buying team at
23
-
MADE uses. We needed to record an extra piece of information for each shipment,
24
-
an optional "delay" field to be used in some ETA calculations. This is a nice
25
-
illustration of a trip all the way through the stack, because things have to
26
-
change all the way from the frontend/UI, all the way down to the database.
24
+
So. Once upon a time, early in my time at MADE, I remember having to make a
25
+
simple change to an app that the buying team uses. We needed to record an extra
26
+
piece of information for each shipment, an optional "delay" field to be used in
27
+
some ETA calculations. This is a nice illustration of a trip all the way
28
+
through the stack, because things have to change all the way from the
29
+
frontend/UI, all the way down to the database.
27
30
28
31
If you're using a framework like Django, you might be used to thinking of a
29
32
change like this, in a perfect world, as a change you can make to just **one** file.
30
-
We change `models.py`, and then our`ModelForm` will be updated automatically,
31
-
and maybe even the frontend, if we're using the form's autogenerated HTML, will
32
-
"just work" too. That's one of the reasons that Django is so good as a rapid
33
-
application development framework; by closely coupling its various parts, it
34
-
saves you a lot of messing about with database tables, html forms, validation,
35
-
and so on. And if those are the main things you spend your time on, then Django
36
-
is going to save you a lot of time.
33
+
You would change `models.py`, and then your`ModelForm` will be updated automatically,
34
+
and maybe even the frontend will "just work" too, if you're using the form's
35
+
autogenerated HTML. That's one of the reasons that Django is so good as a
36
+
rapid application development framework: by closely coupling its various parts,
37
+
it saves you a lot of messing about with database tables, html forms,
38
+
validation, and so on. And if those are the main things you spend your time on,
39
+
then Django is going to save you a lot of time.
37
40
38
41
But in our world (at least in theory [*](#in_theory)),
39
-
database tables and html forms are not where we spend our time. Instead, we
40
-
optimise for making it as easy as possible to capture and understand business
41
-
logic, and as a result we want to _decouple_ things.
42
+
database tables and html forms are _not_ where we spend our time. Instead, we
43
+
want to optimise for capturing and understand business logic, and as a
44
+
result we want to _decouple_ things.
42
45
43
-
What does it cost? Well, let's take a trip through each file I had to change,
46
+
What does it cost? Well, let's take a trip through each file I had to touch,
44
47
when I was making my _very minor_ change to the data model in our app.
45
48
46
-
* I started off with editing a selenium test of the frontend, plus a javascript
49
+
<olstart="0"><li>
50
+
I started off with editing a selenium test of the frontend, plus a javascript
47
51
frontend test, plus the frontend javascript itself, plus an html template.
48
52
That's four files already, but they're not strictly relevant to the patterns
49
53
and layers whose cost I want to account for, so I'm going to say they don't
50
-
count. Don't worry; there's plenty more to come.
54
+
count. If you think I'm cheating, don't worry; there's plenty more to come.
55
+
</li></ol>
51
56
52
57
So:
53
58
54
-
1. An **end-to-end / API test** for the create and edit commands for the objects in question.
55
-
2. The **Command classes** that capture various[write interactions](https://www.cosmicpython.com/book/chapter_10_commands.html) a user can have
59
+
1. An **end-to-end / API test** for the create and edit use cases for the objects in question.
60
+
2. The **Command classes** that capture those[write interactions](/book/chapter_10_commands.html) a user can have
56
61
with this model.
57
-
3. The **command schema** which we use to [validate incoming requests](https://www.cosmicpython.com/book/appendix_validation.html).
58
-
4. The **service-layer tests** which instantiate those commands to test their
62
+
3. The **Command schema** which we use to [validate incoming requests](/book/appendix_validation.html).
63
+
4. The **Service-Layer tests** which instantiates those commands to test their
59
64
handlers
60
-
5. The **handlers at the service-layer** that orchestrate these use cases.
61
-
6. The **domain model tests** that were affected. Although [not every domain model
62
-
needs low-level unit tests as well as service-layer tests](https://www.cosmicpython.com/book/chapter_05_high_gear_low_gear.html), so if I was being indulgent I might
63
-
not count this.
64
-
7. The **Domain Model** itself.
65
+
5. The **Handlers at the Service Layer** that orchestrate these use cases.
66
+
6. The **Domain Model tests** that were affected. Although
67
+
[not every domain model needs low-level unit tests as well as service-layer
68
+
tests](/book/chapter_05_high_gear_low_gear.html),
69
+
so if I was being indulgent I might not count this. But we did happen to
70
+
have a few low-level tests in this case.
71
+
7. The **Domain Model**[itself](/book/chapter_01_domain_model.html).
0 commit comments