Domain Driven Design For Python

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 4:38:03 PM
Duration: 3341.456
Channels: 1
1
00:00:13.585 --> 00:00:27.110
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or you want to try a project you hear about on the show, you'll need somewhere to deploy it. So take a look at our friends over at Linode. With 200 gigabit private networking,
2
00:00:27.645 --> 00:00:44.000
scalable shared block storage, node balancers, and a 40 gigabit public network, all controlled by a brand new API, you've got everything you need to scale up. And for your tasks that need fast computation, such as training machine learning models or running your CI pipelines, they just launched dedicated CPU instances.
3
00:00:44.935 --> 00:00:50.875
In addition to that, they just launched a new data center in Toronto, and they've got 1 opening in Mumbai at the end of 2019.
4
00:00:51.415 --> 00:00:52.635
Go to python podcast.com/linode,
5
00:00:54.135 --> 00:01:12.815
that's l I n o d e, today to get a $20 credit and launch a new server in under a minute. And don't forget to thank them for their continued support of the show. And to keep track of how your team is progressing on building new features and squashing bugs, you need a project management system that can keep up with you that's designed by software engineers for software engineers.
6
00:01:13.740 --> 00:01:23.735
Clubhouse lets you craft a workflow that fits your style, including per team tasks, cross project epics, a large suite of prebuilt integrations, and a simple API for crafting your own.
7
00:01:24.115 --> 00:01:28.535
With such an intuitive tool, it's easy to make sure that everyone in the business is on the same page.
8
00:01:29.350 --> 00:01:29.850
Podcast.init
9
00:01:30.230 --> 00:01:33.850
listeners get 2 months free on any plan by going to python podcast.com/clubhouse
10
00:01:35.430 --> 00:01:37.530
today and signing up for a free trial.
11
00:01:37.995 --> 00:01:40.095
And you can visit the site at python podcast.com
12
00:01:40.715 --> 00:01:48.649
to subscribe to the show, sign up for the mailing list, read the show notes, and get in touch. And if you have any questions, comments, or suggestions, I'd love to hear them.
13
00:01:49.590 --> 00:02:04.040
And to help other people find the show, please leave a review on Itunes and tell your friends and coworkers. Your host as usual is Tobias Macy. And today, I'm interviewing Harry Percival about domain driven design and enterprise application architecture in Python. So, Harry, could you start by introducing yourself?
14
00:02:04.680 --> 00:02:12.220
Hi, Tobias. Thank you very much for having me. So my name is Harry. I'm a Python programmer from the UK. I've been doing Python for maybe
15
00:02:13.254 --> 00:02:17.674
10, 11 years. And, at the moment, I work at a sort of furniture retailer
16
00:02:18.295 --> 00:02:20.155
or design brand called made.com.
17
00:02:20.670 --> 00:02:21.489
We sell kind of
18
00:02:21.790 --> 00:02:23.090
furniture and other homewares
19
00:02:23.470 --> 00:02:24.769
throughout the UK and Europe.
20
00:02:25.230 --> 00:02:30.114
And for anybody who hasn't encountered you before, they might know you from your,
21
00:02:30.815 --> 00:02:35.315
Obey the Testing Goat book or from your fantastic jokes at various pythons.
22
00:02:36.690 --> 00:02:38.230
Yeah. Sure. That's right. So,
23
00:02:38.930 --> 00:02:43.030
my my my previous career or my previous job before this was at a startup
24
00:02:43.569 --> 00:02:47.925
called Python Anywhere, which is a kind of Python hosting platform as a service type of thing.
25
00:02:49.585 --> 00:02:54.170
And even before that, that was a company that morphed out of a spreadsheet company. It used to build
26
00:02:54.790 --> 00:03:07.204
a kind of Python based spreadsheet like Excel, but with Python as the kind of scripting language, which is really cool. And I joined them as a kind of an intern during my my second degree, and that is now,
27
00:03:08.224 --> 00:03:09.490
2,009, I think.
28
00:03:09.970 --> 00:03:16.655
And they were an extreme programming shop, so they did XP. They did test driven development for absolutely everything. They did pair programming on everything.
29
00:03:17.135 --> 00:03:19.315
And, basically, after a couple of years of that,
30
00:03:19.694 --> 00:03:23.155
I wrote a book about it, which which was called Test Driven Development with Python,
31
00:03:23.535 --> 00:03:25.790
just saying, you know, for self taught programmers,
32
00:03:26.330 --> 00:03:31.069
here's here's a kind of restructured rigorous way to approach coding. Test first, incremental,
33
00:03:31.610 --> 00:03:37.575
you know, version control, all this good stuff. And I'm wondering if you can just share how you first got introduced to Python.
34
00:03:37.955 --> 00:03:38.935
Yeah. So, actually,
35
00:03:39.315 --> 00:03:40.135
when I was,
36
00:03:40.675 --> 00:03:42.970
I mentioned spreadsheets. While I was kind of,
37
00:03:43.770 --> 00:03:45.950
paying my way through my university degree,
38
00:03:46.410 --> 00:04:00.349
I had a client. And I would basically help him build these these spreadsheets, which were like pricing models that he would use to go out to do competitive tenders for legal services. And, like, the, you know, the lawyers would fill in, like, these spreadsheets to say what kind of prices they would do for different things.
39
00:04:00.650 --> 00:04:14.820
And and then, you know, having been doing this to view in computer programming for a couple of years, I eventually said to him, you know, like, we could we could stop using spreadsheets, and we could build this as a web application. And people could, like, submit their pricing, and then we can have a UI for, you know, clients to to go and find the best price and stuff.
40
00:04:15.300 --> 00:04:17.720
And that was my first kind of real
41
00:04:18.260 --> 00:04:19.880
consulting engagement, my first real
42
00:04:20.420 --> 00:04:23.965
programming client. And he said, that sounds good. You know? I trust
43
00:04:24.345 --> 00:04:33.789
you. And, he says, tell you what. Since you've never really built a website before, why don't you call up my hosting company and get them to just support you? Now at least provide the hosting and give you some advice.
44
00:04:34.169 --> 00:04:45.095
So I called them up and I said, hey. What's up? I thought I was gonna build this thing. And they're like, right. Well, we use Django, so that's we recommend you use. And so I said, okay. I'll give it a go. And so I think it was just before Christmas,
45
00:04:45.634 --> 00:04:48.539
I went home for the Christmas break with,
46
00:04:49.000 --> 00:04:50.780
a copy of Dive Into Python
47
00:04:51.720 --> 00:04:55.500
and a copy of, I think the the original Django book.
48
00:04:55.914 --> 00:05:04.320
I basically read those 2 things over the Christmas holiday and sort of came back having taught myself Python and Django as best I could in the space of kind of 2 weeks,
49
00:05:04.700 --> 00:05:06.400
and and I was off to the races.
50
00:05:06.780 --> 00:05:09.520
Yeah. That's definitely 1 of the great things about Python
51
00:05:09.820 --> 00:05:30.725
and Django in particular is that it is approachable enough where that's something that's feasible as opposed to if you had gone home with a, teach yourself c plus plus book and whatever passes for a web framework in that community. I'm sure it probably would have taken a bit more than just the 1 Christmas break to be Right. Right. I mean, it it's so often in the in the case in the in the Python world of of you know, I I say to people who are just learning a car, you know,
52
00:05:33.689 --> 00:05:40.189
oh, gosh, I have to learn this whole programming language. And I'm just I just say to them, you know, actually, especially if you already know a bit of programming,
53
00:05:40.729 --> 00:05:52.729
the way Python does it is kind of the most straightforward and intuitive way you can think of. You know, like it like, what's the simplest and most obvious way I could do a for loop? I want iterate for all the items in array. How about for item in array?
54
00:05:53.110 --> 00:05:54.650
And, like, literally those words,
55
00:05:55.590 --> 00:05:56.650
colon. And
56
00:05:57.190 --> 00:06:01.075
and so many things like that. You know, it's it's all about pipe and strength in saying
57
00:06:01.635 --> 00:06:02.615
there should be 1,
58
00:06:02.995 --> 00:06:07.655
preferably only 1 obvious way to do it. Yeah. And so in your work of building
59
00:06:08.035 --> 00:06:08.535
applications
60
00:06:09.075 --> 00:06:10.055
and supporting
61
00:06:10.435 --> 00:06:14.520
other members of your team and working in these extreme programming environments,
62
00:06:15.060 --> 00:06:16.520
you appear to have
63
00:06:16.820 --> 00:06:19.725
gotten bitten by the bug of being interested
64
00:06:20.185 --> 00:06:21.405
in application architecture
65
00:06:22.025 --> 00:06:24.365
and the concepts of domain driven design.
66
00:06:25.065 --> 00:06:26.440
And I know that,
67
00:06:27.000 --> 00:06:32.540
architecture is a very broad term. It encapsulates a lot of different ideas and potential approaches and
68
00:06:32.920 --> 00:06:33.820
design patterns.
69
00:06:34.585 --> 00:06:37.485
And the concept of enterprise application architecture
70
00:06:37.945 --> 00:06:39.005
is something that
71
00:06:39.385 --> 00:06:41.885
grew largely from the Java community.
72
00:06:42.379 --> 00:06:43.280
And so I'm wondering
73
00:06:43.659 --> 00:06:45.680
if you can just start by describing
74
00:06:46.060 --> 00:06:48.720
what you mean when you're talking about application architecture
75
00:06:49.099 --> 00:06:56.355
and how it compares to some of the typical types of design patterns that Python developers rely on. Yeah. Yeah. Yeah. Absolutely.
76
00:06:56.815 --> 00:06:57.315
So
77
00:06:57.775 --> 00:06:58.100
the
78
00:06:58.820 --> 00:07:04.280
I'm a bit scared of the word enterprise. It's not there there is a subject called enterprise architecture, and that's really about
79
00:07:04.580 --> 00:07:10.645
building a strategy for a large company for how are they going to evolve their portfolio of applications from
80
00:07:11.025 --> 00:07:18.480
their, you know, what's insourced, what's outsourced, what do they buy off the shelf, you know, and they're people call enterprise architecture to kind of build technology strategies,
81
00:07:19.100 --> 00:07:32.750
for for big companies. And that's kind of you know, a smaller company, that would just be the role of the CTO. So I'm not here to talk about enterprise architecture, and I'm really talking about application architecture, insofar as everyone agrees on on that bit of terminology.
82
00:07:33.450 --> 00:07:36.030
And to sort of explain what that is,
83
00:07:36.490 --> 00:07:39.710
design patterns is a thing. So people might have heard of design patterns.
84
00:07:41.915 --> 00:07:45.695
I'm talking about architectural patterns. Are they the same thing? Not really.
85
00:07:46.235 --> 00:07:49.840
Design patterns, which are the classic Gang of 4 book,
86
00:07:50.220 --> 00:07:54.400
was about giving you suggestions for how to build particularly
87
00:07:54.945 --> 00:07:56.485
code in the object oriented,
88
00:07:57.185 --> 00:08:05.550
paradigm. And it's things like singleton pattern, abstract factory, blah, blah, blah. And and lots of people out there in the Python community have spoken a bit about design patterns,
89
00:08:06.090 --> 00:08:10.925
and particularly saying the way that, you know, something like 40% of those patterns that are famous and from that
90
00:08:11.485 --> 00:08:13.985
book aren't really applicable in the Python world because,
91
00:08:14.685 --> 00:08:24.520
in a way, they're workarounds for for features of the Java language that are just not really necessary in in the lovely dynamic world of Python. So I'm not here to talk about design patterns.
92
00:08:24.820 --> 00:08:27.320
I'm talking about application architecture. And I suppose
93
00:08:27.675 --> 00:08:31.535
application architecture is a level of section higher than design patents.
94
00:08:31.915 --> 00:08:38.709
And it's about saying, how do I build my application as a whole? How do I side how to structure my code? How do I
95
00:08:39.170 --> 00:08:42.230
side how to split it up? How do I side what code to put where?
96
00:08:42.930 --> 00:08:44.765
And and to make that more concrete,
97
00:08:45.464 --> 00:08:51.245
for people, 1 of the most common architectural patterns that people have heard of is MVC, Model View Controller.
98
00:08:51.625 --> 00:08:55.070
And so the idea is I'm gonna split my application up into a kind of model,
99
00:08:56.010 --> 00:09:00.350
which talks about the data and the way I model the data. And then I'm gonna have
100
00:09:00.730 --> 00:09:07.685
some views, which is how do I present the data to the user. And then I'm going to have some controllers, which are going to say, okay, well, given that the user,
101
00:09:08.225 --> 00:09:11.125
asks me to do these sorts of things, how do I
102
00:09:11.760 --> 00:09:19.780
control, orchestrate, put together that request with things from the model, and and build a response back for the user? That's Model View Controller.
103
00:09:20.160 --> 00:09:26.545
And then in the Django world, that translates more or less to the way Django asks you to structure things into
104
00:09:27.004 --> 00:09:38.305
models which represent database modics and templates which are the kind of views of data and what Django calls view functions which are maybe more equivalent to controllers and MVC. But they're both examples
105
00:09:38.605 --> 00:09:48.640
of a layered architecture which says, you know, I'm gonna build my application in layers. There's gonna be the lower layer of the data stuff. There's gonna be a kinda middle layer of business logic and and controllers,
106
00:09:49.340 --> 00:09:51.760
and there's gonna be a presentation layer at the top.
107
00:09:52.380 --> 00:09:56.654
That that's the most, like, well known and and familiar architectural pattern probably.
108
00:09:57.035 --> 00:10:00.574
1 of the interesting things about the idea of application architecture
109
00:10:01.500 --> 00:10:04.080
is that there has been a bit of pushback
110
00:10:04.460 --> 00:10:14.264
on the idea of upfront design with the advent of things like agile programming and the idea that we're trying to move away from waterfall where you
111
00:10:14.644 --> 00:11:00.890
put everybody into a room for days or weeks. You write out everything about how the software is going to operate, and then you just go and spend all of your time building it exactly to that specification, which, as we all know, never works out the way that we plan. And so we've kind of gone to the extreme other end where rather than putting in a decent amount of thought into how everything needs to be modeled, we just say, we're just gonna start writing code, and we're gonna figure it out as we go, and everything will be wonderful, which also doesn't usually work out. And so I think as an industry, we're starting to oscillate back to a middle ground of actually having some of this upfront design, trying to get an understanding of the domain that we're working with, but still being able to approach the actual implementation in a agile and iterative approach. And I'm wondering what, in your experience, are some of the influences
112
00:11:01.510 --> 00:11:06.795
in general, whether in team dynamics or industry dynamics that tend to lead engineers into
113
00:11:07.255 --> 00:11:16.380
suboptimal architectures that end up becoming brittle or coalescing into the dreaded big ball of mud and some of the ways that you can potentially guard against those influences.
114
00:11:16.680 --> 00:11:19.980
Yeah. There's a there's a bit to unpack there. But I guess
115
00:11:20.680 --> 00:11:52.700
if the if the idea is, okay, you know, let's not worry too much about design upfront. We're just gonna be agile. Let's build something as quickly as you can. The way we do that is we pick a framework like Django. And Django's, you know, tagline is this, the framework for perfectionists with deadlines. And so it's saying, you know, here's the thing, it's going to get you up and running really quickly and it's going to let you meet some deadlines. And so I'm not gonna think too much about architecture. I'm gonna pick this framework. But what you've actually done is picked an architecture without thinking about it. And so Django is pushing you towards this kind of, layered architecture with kind of models and views and templates.
116
00:11:53.400 --> 00:12:01.645
And and that's fine, and it's very successful, and it gets you to a lot of places very quickly. But I think it does run into some problems as things scale. And I think in the in
117
00:12:02.185 --> 00:12:07.959
the in the Python world, we're starting to see some of the problems that that other languages and other communities have been through,
118
00:12:08.500 --> 00:12:34.595
a long time ago. And so once you know, if you're just building a startup and you're building a web application and you're you're you're up and running for the 1st couple of years, Django is great and Flask is great and whatever it is. But after a while, you can run into limitations of that simple 3 layered architecture. Firstly, because it's not always even that easy to stick to that 3 layered architecture if you're not thinking about it. But even if you do, you know, you can run into problems. And so any application that grows to a certain level of complexity,
119
00:12:35.055 --> 00:12:52.855
if you don't have a sort of reasonably structured way of thinking about, okay, well, like, where am I gonna you know, here's a new bit of functionality. Where am I gonna keep the code for this? Where is the place that's gonna make it easy to maintain, that's gonna make it testable? Then you will end up with a slightly haphazard approach, and you're gonna end up with the classic problems of of the increasing complexity of applications.
120
00:12:53.555 --> 00:13:02.850
The the kind of the jargon is the big ball of mud where everything kind of depends on everything else. And that, you know, making sort of 1 part of the system over here is hard to disentangle from from places over there. Or you just find yourself, due to the architecture of your framework, finding that, you
121
00:13:08.975 --> 00:13:15.875
you know, your tests are just getting slower and slower. So it might even be that your application is quite well structured. But, you know, your test suite that used to run-in
122
00:13:16.380 --> 00:13:39.300
under a second is now taking an hour and a half to get through CI. Or, you know, in the case of Python anyway, which is admittedly a bit of a a unique case, but it was taking, you know, half a day. I'm not saying that's, you know, particularly because Python Anywhere made, bad architectural choices. It's a unique case. But what I'm saying is, you know, what works really well at a small scale, you can start to struggle with as you as you grow.
123
00:13:39.605 --> 00:13:40.105
And
124
00:13:40.565 --> 00:13:41.785
so 1 of the
125
00:13:42.325 --> 00:13:49.225
core concepts in the problem space of application architecture that has been adopted by more mature organizations
126
00:13:49.529 --> 00:13:52.830
and language communities is the idea of domain driven design,
127
00:13:53.290 --> 00:13:57.390
which has proven fairly successful in terms of being able to support large
128
00:13:57.875 --> 00:13:59.495
applications and large organizations
129
00:14:00.435 --> 00:14:05.735
as well as some of these evolutionary and iterative cycles of development practice.
130
00:14:06.110 --> 00:14:12.770
And so I'm wondering if you can just unpack the term there and some of the benefits that it provides to software architecture
131
00:14:13.365 --> 00:14:16.505
in general and some of the core concepts that are necessary
132
00:14:17.285 --> 00:14:21.290
to get introduced to that approach to application design? Sure thing.
133
00:14:21.590 --> 00:14:22.070
So,
134
00:14:22.550 --> 00:14:28.525
domain driven design is a a kind of, a philosophy for for how to build applications, but also how to approach
135
00:14:29.085 --> 00:14:52.195
your conversations with your stakeholders, with your business, so the the, you know, kind of requirements gathering side as well as just the coding side. And the the central conceit of it is that the most important part of an application is the model of the core domain, the core business domain, which, you know, maybe you'd use the word business logic or business rules or the representation of the problem space. And that is the beast
136
00:14:52.735 --> 00:15:04.779
that delivers the most value and the conceit is saying, look, if get this right, if we have a model that really does capture the essence of the business and the way it does things or the way it understands the world, then that model
137
00:15:05.505 --> 00:15:08.565
will A, be really easy to understand for both the business and developers.
138
00:15:08.945 --> 00:15:17.399
The application will be in sync and in tune with the business so it's gonna help them do their jobs more. And it may also even enable possibilities that people didn't even realize
139
00:15:17.860 --> 00:15:25.774
were there. So if I've done a really good part a a job of modeling the business, I may suddenly be able to say, hang on. This concept and this concept, we can now bring these things together.
140
00:15:26.475 --> 00:15:53.370
And, you know, did you realize that we could do this and sell this product in this way or or or deliver this service in this manner? So that's the that's the central conceit is the most important thing is is is modeling the domain. And so domain driven design is a series of kind of techniques and methodologies and ways of coding that try and bring that to the front. Having conversations with the business and trying to build what he calls a ubiquitous language. So, business people have jargon. If developers sit there and try and really understand that jargon
141
00:15:53.830 --> 00:16:01.275
and understand nuances of it, get rid of ambiguities, and then they can decide on single words to define concepts in a certain context,
142
00:16:01.655 --> 00:16:07.000
then you can have the code and the way that you talk to your business be the same. So that when you say,
143
00:16:07.860 --> 00:16:14.005
sales order, you know, everyone understands that that is is an order from a customer, not an order from the company to China to get a
144
00:16:15.105 --> 00:16:15.764
piece of,
145
00:16:16.144 --> 00:16:17.925
furniture or something, for example.
146
00:16:18.384 --> 00:16:22.750
There are some other approaches to software design and application architecture
147
00:16:23.130 --> 00:16:28.110
that have gained some level of popularity. And I'm wondering if you can just briefly
148
00:16:28.445 --> 00:16:31.505
outline some of the other common approaches and
149
00:16:31.885 --> 00:16:37.660
why you think that domain driven design in particular is worthy of additional attention and,
150
00:16:38.139 --> 00:16:49.705
exploration for people who are working in the Python space. Well, I guess what you'd contrast with it is sort of letting things evolve naturally over time. And and I think what I found is in my experience, you know, I've worked at some places where there isn't really a domain.
151
00:16:50.245 --> 00:16:51.545
Like your Python application
152
00:16:52.165 --> 00:16:57.210
is a very thin layer over a database, really. We're just letting people create read update records.
153
00:16:57.590 --> 00:17:12.850
So is there a complex domain with a lot of business rules there? No. Or in that case, maybe you don't need to go to the full extent of building a complex model. Right. And so, I think the ways that this gets more relevant in the Python world is as we as our applications
154
00:17:13.630 --> 00:17:14.130
start
155
00:17:14.590 --> 00:17:16.770
to be more than just kind of data pipelines
156
00:17:17.225 --> 00:17:21.725
or or, glorified shell scripts or you know, if you look at, Dropbox,
157
00:17:22.345 --> 00:17:31.409
that was basically just building a UI around a file system on a server that wasn't in your house. Like, it's a web UI over a file system. So, you know, to a certain extent,
158
00:17:31.855 --> 00:17:35.955
there wasn't much domain there for a while, although I'm sure as that's grown in complexity,
159
00:17:36.495 --> 00:17:44.169
they've grown their own way of thinking and talking about these things and there is 1 now. I guess that's what I'm saying is it's something that really pays off when you have
160
00:17:45.510 --> 00:17:47.450
a business domain of sufficient complexity
161
00:17:47.990 --> 00:17:48.490
that
162
00:17:49.015 --> 00:17:56.535
the, you know, the the conceit of domain driven design which is that the modeling the domain correctly is what will give you the most value is true. Perhaps it's a bit of a,
163
00:17:57.175 --> 00:17:58.430
a self referential argument but
164
00:17:59.390 --> 00:18:02.610
I think you can see what I'm driving at. And so domain driven design
165
00:18:02.990 --> 00:18:10.755
is something that brings with it this idea of as you said, there is a business domain that you're trying to be able to model effectively,
166
00:18:11.055 --> 00:18:32.455
but there might be situations where the project that you're working on is small enough scope or with a small enough number of people where you feel, oh, I can just go ahead and code something out in an afternoon. It'll do exactly what I want. It's never going to evolve beyond this. Is that just a logical fallacy and everything ultimately converges towards a big ball of mud? Or do you think that there are actually cases where domain driven design is,
167
00:18:33.110 --> 00:18:40.970
just more effort than is absolutely necessary for a particular type of project? No. I I think absolutely. It it it can be, you know, more effort than you need to go to.
168
00:18:41.435 --> 00:19:07.450
And, like, if the very fact, you know, if it's all about having conversations with domain experts so that that you're finding experts in the domain and having a conversation with between you and your, you know, your programming team. And if you sit there and are asking the question like who is the domain expert? Then, you know, if there's no domain expert and it's just you, then there's probably nothing to it. Similarly, I guess 1 of the, you know, you mentioned other architectural patterns. I suppose 1 of the things that that,
169
00:19:08.309 --> 00:19:11.290
is kind of related to DDD is is microservices,
170
00:19:11.910 --> 00:19:18.034
which is very much the kind of buzzword architectural pattern of the moment. I just came back from a conference called, MuConf
171
00:19:18.414 --> 00:19:19.955
which is kind of short for microservices.
172
00:19:20.575 --> 00:19:25.590
And that's a it was actually the merger of a DDD conference and a microservices
173
00:19:25.890 --> 00:19:29.029
conference. And the 2 have meshed together very well.
174
00:19:29.570 --> 00:19:30.470
And that's because
175
00:19:30.929 --> 00:19:31.075
1
176
00:19:31.955 --> 00:19:36.054
1 of the main concepts of DDD is trying to identify bounded contexts.
177
00:19:36.434 --> 00:19:38.455
So, if you have a big enough company,
178
00:19:38.914 --> 00:19:43.790
there's not 1 domain model. The company has different capabilities. It needs to be able to,
179
00:19:44.490 --> 00:19:53.345
I don't know, it needs to be able to invoice customers. It needs to be able to purchase inventory. It needs to be able to sell it to customers. It needs to be able to do after sales service.
180
00:19:53.805 --> 00:19:55.745
And your conception of a customer
181
00:19:56.220 --> 00:20:04.240
can be different depending on what context of the company you're talking about. And DDD has always, you know, said 1 classic mistake is to build a single
182
00:20:04.620 --> 00:20:12.235
class to represent your customer and try and make it serve all of the use cases in the whole company. And pretty soon, your customer object is unbelievably
183
00:20:12.695 --> 00:20:26.775
complicated and hard to maintain. And, you know, it has fields called slightly different things for different cases. And it's, you know, because it's used everywhere, it's hard to modify because you impact every single area of the company when you try and modify the customer object.
184
00:20:27.155 --> 00:20:29.895
And that in the Django world, it's the sort of giant
185
00:20:30.275 --> 00:20:31.095
user profile
186
00:20:31.635 --> 00:20:38.580
kind of anti pattern. And what DDD says is, listen, what you need to do is identify bounded contexts where you've got a sort of reasonably coherent
187
00:20:38.960 --> 00:20:41.539
piece of business functionality, a reasonably coherent domain.
188
00:20:41.840 --> 00:20:46.935
And what you're gonna do is model that domain and not the other 1. So like what is the user as far as,
189
00:20:48.275 --> 00:20:59.000
sales orders are concerned? That's 1 thing. And then over here, what is the user as far as, I don't know, monthly billing is concerned? Then it might be a different concept. You know, 1 might have an address, the other 1 might not.
190
00:21:00.020 --> 00:21:15.510
And and they would tend to say, let's let's isolate those concepts. And then the 2 should be reasonably independent. And if they ever need a d to talk to each other, we'll have a translation layer. You know, we'll have a way of translating the user as far as sales orders are concerned to the user as far as invoicing is concerned. But we want to keep them separate.
191
00:21:16.130 --> 00:21:29.570
And that can work in the context of a of a monolithic application, but it also obviously ties in very nicely with the idea of saying, actually, maybe my sales order service and my invoicing service, you know, parts of my application should be different services. They should be microservices.
192
00:21:30.509 --> 00:21:46.220
And then you can get into splitting hairs about how tiny a microservice should be, but it is something that fits very well We're trying to talk about decomposing monoliths. We're trying to talk about, like, what makes a single coherent application. So application architecture in this sense of deciding what is an application, what should be multiple applications.
193
00:21:46.760 --> 00:21:51.420
Hope that made sense. Yeah. That made good sense. I I definitely think that 1 of the
194
00:21:51.800 --> 00:21:56.345
valuable pieces of DDD in general is this focus on understanding
195
00:21:56.965 --> 00:21:57.945
what are the boundaries
196
00:21:58.325 --> 00:22:08.200
of the different problem spaces that I'm trying to I'll just bolt on this other piece that isn't really part of the core concern
197
00:22:08.580 --> 00:22:22.929
because I'll just bolt on this other piece that isn't really part of the core concern because it's fast for me to just get it out the door. And that's what starts leading people towards this big ball of mud because they just say, oh, I'll just bolt something on here. Oh, this already isn't quite exactly what the semantics
198
00:22:23.230 --> 00:22:34.815
are sort of implying it's supposed to do, but, you know, I can just spend 5 minutes getting this working instead of a day and a half redesigning how this is going to work and, you know, future proofing against
199
00:22:35.290 --> 00:22:41.870
some of the, accretion of technical debt that would happen otherwise. Yeah. Absolutely. I mean, we've always got this tension between,
200
00:22:42.170 --> 00:22:46.535
you know, trying to anticipate future problems and, build a design that is going
201
00:22:46.915 --> 00:22:50.295
to manage complexity for the future and make our lives easier and maintainable.
202
00:22:50.675 --> 00:23:06.025
And just saying, you know, you ain't gonna need it. Alright. Yeah. Fine. Maybe if I was building some huge piece of enterprise software, then it would be really sensible to put all these layers in and build all this indirection. But I'm just trying to to build, you know, a social network for pet owners. I don't know. I'm just trying to build my little thing.
203
00:23:06.885 --> 00:23:13.670
Is it not really worth it? Or do how do I know that it's now is the right time to start being rigorous and disciplined about architecture?
204
00:23:14.130 --> 00:23:18.845
I don't have any, magic answers to that. But what I do have is is some suggestions for,
205
00:23:20.025 --> 00:23:22.605
okay, people in the world of DDD which is
206
00:23:22.905 --> 00:23:24.205
often the world of Java
207
00:23:24.505 --> 00:23:25.085
and C
208
00:23:25.784 --> 00:23:27.430
have been doing this kind of modeling of
209
00:23:31.510 --> 00:23:33.050
ideas about how you
210
00:23:33.350 --> 00:23:40.145
build a model and the kinds of problems that you're always gonna encounter and some classic solutions to it. So these concepts like,
211
00:23:40.525 --> 00:23:41.105
you know,
212
00:23:41.485 --> 00:23:44.545
in your classes that represent your model, distinguishing between,
213
00:23:45.320 --> 00:23:52.460
and there's some jargon here, I don't know how much detail we want to go into, but distinguishing between value objects that have no identity over time and are replaceable,
214
00:23:52.760 --> 00:24:13.965
and entities, which are objects that represent something in the real world that has an entity that varies over time even though its attributes may change over time. And finally, aggregates, where we're saying, when I've got lots of classes in my model, I'm gonna put some individual models to be in charge of a bunch of others, and they are gonna be the only, way of modifying the state so that I have a single,
215
00:24:14.505 --> 00:24:16.924
object or class that's in charge of my
216
00:24:17.385 --> 00:24:17.885
consistency
217
00:24:18.280 --> 00:24:20.620
rules, my invariance, my integrity rules.
218
00:24:21.000 --> 00:24:38.410
So promoting some of your models to being kind of public models in the same way as you have private and public methods. And, you know, you can you can hear that there's kind of language and and ways of thinking that have come out of the of the o 0 world, which, you know, we're all a bit suspicious of in the Python world. You know, when someone says to me, you know, private methods,
219
00:24:38.950 --> 00:24:52.840
like the whole point of Python is that we're grown ups. Nothing is private. You can put an underscore in it if you want, but I, you know, reserve the right to look at that. But these things that, you know, all all exist for a reason. And once you have a certain level of complexity, these kind of patterns and tools for managing complexity,
220
00:24:53.380 --> 00:24:58.440
really do come into their own. And the nice thing is is that when you do them in Python, you know, you don't have to sit there
221
00:24:59.275 --> 00:25:01.455
writing public static void main
222
00:25:01.835 --> 00:25:04.335
and all the all the kind of Java verbiage.
223
00:25:04.875 --> 00:25:06.815
You can have this kind of quite lightweight
224
00:25:07.195 --> 00:25:20.385
way of of building abstractions and building a structure into your application that doesn't feel, as heavyweight as as some of the things you get into with interfaces and and whatnot in Java. And I think that this is a good point too to start digging into
225
00:25:20.765 --> 00:25:26.950
the actual implementation details of some of these patterns. Because as you're mentioning, there are these ideas of interfaces
226
00:25:27.330 --> 00:25:34.925
where I have this, sort of abstract base class that says that any class that inherits from it is going to have these types of methods.
227
00:25:35.545 --> 00:25:44.470
So as long as I have something that implements the actual business logic behind them, then I could plug this in anywhere, which then feeds into the idea of dependency injection or inversion of control.
228
00:25:44.770 --> 00:25:50.825
And so in the Java world, often means that there is some sort of dependency injection framework. And I have seen
229
00:25:51.125 --> 00:26:02.070
various attempts to port those ideas and even very Java esque implementations into the Python community or the the Python landscape, which usually doesn't translate very well.
230
00:26:02.370 --> 00:26:03.190
And so I'm wondering
231
00:26:03.570 --> 00:26:12.325
if you can just talk through some of the ways that you approach these ideas in Python that leverage the native capabilities of the language while still
232
00:26:12.705 --> 00:26:16.405
maintaining the core benefits of the ideas without necessarily
233
00:26:16.720 --> 00:26:22.180
catapulting somebody into Java. Yeah. Right. Well, so I guess it's maybe it's time then to talk a little bit about,
234
00:26:22.640 --> 00:26:55.595
dependency injection and the the closely related and more important topic of of dependency inversion. So so 1 of the the patterns or rules of thumb, I tell you what, Bob Martin has been popularizing this recently so people who've read Clean Architecture which I hasten to add that I haven't. And maybe this is a good time to add a caveat that says, like, I am not an expert in this stuff. I have been learning about all these sorts of architectural patterns while I've been at Made, which is about 18 months now. But the experts are the is the well, probably, I'll just say is Bob, the lead architect here who came from the c sharp world and has seen all this stuff in his previous
235
00:26:56.075 --> 00:27:07.250
careers. So, I'm I'm a little bit talking about things I don't fully understand. But with that caveat in mind, dear listener, the idea of of, dependency inversion is saying it's this rule that says that
236
00:27:07.550 --> 00:27:11.010
our high level model should not depend on details. They should depend on abstractions.
237
00:27:11.470 --> 00:27:14.595
And actually, some of our popular frameworks like Django
238
00:27:15.295 --> 00:27:20.995
do this for us already. They say, Okay. Well, listen. If I was building a model class to represent
239
00:27:21.295 --> 00:27:28.490
my domain, I'm gonna build a class to represent orders and a class to represent customers and whatever, I know that at some point I'm gonna wanna save that to the database.
240
00:27:29.190 --> 00:27:43.160
So the kind of naive way of doing that is to say, okay, well, let's have my model kind of import and do a bunch of SQL code and it will know how to save itself to the database by writing some raw SQL. And then my model depends on a detail because the specific
241
00:27:43.460 --> 00:27:56.215
dialect of SQL in a specific database that I've chosen or even the fact that I've chosen to persist to a SQL database rather than a NoSQL database or to the file system is a detail. It's an infrastructure detail. It's an implementation detail. And you can build code where your
242
00:27:56.515 --> 00:27:59.260
high level modules, your domain should be the highest level module,
243
00:27:59.640 --> 00:28:00.460
depends on,
244
00:28:01.000 --> 00:28:10.305
infrastructure details. And the dependency inversion principle says, well, let's let's flip that on its head. What we want to say that, you know, our model shouldn't depend on the database,
245
00:28:10.685 --> 00:28:12.385
it should depend on an abstraction,
246
00:28:12.765 --> 00:28:14.705
and then the database can depend
247
00:28:15.150 --> 00:28:21.730
on the abstraction as well. And that's what Django does. It says, okay, well, your model doesn't know about the database directly. It knows about an abstraction
248
00:28:22.110 --> 00:28:23.725
which is the djangomodels.modelclass.
249
00:28:25.385 --> 00:28:39.095
So we already kind of are used to doing this and it's about taking it to the next level really. And it's saying, okay, well, even you know, your model maybe depends on the Django models dot model class, it still depends on some sort of infrastructure. Yes. Your
250
00:28:39.975 --> 00:29:06.309
your, framework, you know, has made it easy to swap Postgres for MySQL, but you've still got a dependency there. And so when you want to run all your tests, you have to instantiate some sort of database. And some of the architectural patterns we're talking about is saying, well, let's really invert that dependency all the way and say rather than having the model depend on the database, even if it's an abstraction of the database, let's have the model depend on nothing at all. And instead, we'll have the database look in at the model. So instead of like, you know, my model class is importing
251
00:29:06.769 --> 00:29:07.269
django.db.models,
252
00:29:08.370 --> 00:29:19.715
I'm gonna have some sort of database module import my domain model and say, okay, let me if I want to build my database, let's go and have a look at the models and we'll figure out which, you know, which tables will map to which columns
253
00:29:20.015 --> 00:29:23.154
the other way around. I'm not sure if I've explained that very well,
254
00:29:24.000 --> 00:29:25.700
Tobias. Maybe you've got some questions.
255
00:29:26.320 --> 00:29:59.299
No. I think you did a good job of talking that through. And for anybody who wants to dig a bit deeper, we can provide some links to, maybe some visuals that will make it a little easier to grok, because something like this is definitely hard to encapsulate fully just through a podcast. And also, you know, we we haven't touched on this yet, but you are working on a book that is intended to cover a lot of these different topics. And in the process of preparing for this conversation, I was reading through bits of it, and I think that you did a very good job of talking through that specifically in terms of the Django ORM versus SQLAlchemy
256
00:29:59.600 --> 00:30:18.200
and some of the ways that you can approach it. And so I'll add links to those specific pages as well for somebody who wants to dig a bit deeper. Great. Well, I mean, it's maybe that's an interesting thing to talk about because my last book was all about testing, and these architectural patterns can really help with testing. And so I think near the end of the book, I said, listen, how do you decide
257
00:30:18.659 --> 00:30:19.159
how
258
00:30:19.539 --> 00:30:23.304
to, what kind of test to write? You know, you're gonna have you could have some unit tests.
259
00:30:24.245 --> 00:30:43.315
If you're doing Django, you have these sort of kind of unit tests, but maybe they're gonna use a real database of some kind or even an in memory SQLite database, but they're gonna be a little slower. We were just talking about how that can be a bit of a break on development. You can have integration tests where you're gonna check the boundaries between your systems, like, can I really talk to a database? Can I talk to a third party API? Whatever it'll be. And you might have end to end tests where, you know, if you
260
00:30:48.200 --> 00:31:15.325
if you follow my book, you're gonna drive a browser with Selenium and use a real database. But, you know, even if it's just an API, you know, you're actually gonna spin up some containers and a thing that looks like your production system and test end to end whether, you know, everything is really wired together. And we started taking talking in the book about, okay. Well, how do we decide what kind of test to write and how many of which ones? And and we know that the end to end tests are the ones that give us the most reassurance about our system working, but they're also the slowest. So they give us the slowest
261
00:31:15.784 --> 00:31:38.779
feedback and the the least information about whether our design is correct. And we know that the unit tests are the fastest and they give us the most feedback about, like, individual low level bits of design, like, is this piece of code well written? Is it easy to use? Is it easy to test? But on the other hand, you never know if you've pulled all your units together. And so, you know, you read around this stuff and everyone says, well, the test pyramid. Okay. The answer is you want a pyramid
262
00:31:39.159 --> 00:31:45.455
such that you have a few kind of end to end tests on top. You have a sort of middle layer of integration y tests,
263
00:31:45.915 --> 00:31:50.050
where you have a few more of those but not too many. And then you try and have the bulk of your
264
00:31:50.610 --> 00:31:52.630
application tested through unit tests.
265
00:31:53.410 --> 00:31:59.945
And this always seems like like great advice. And then you go away and you build your Django app and you find that, you know, actually doing that in real life is quite hard.
266
00:32:01.225 --> 00:32:06.764
And what I've found from some of the architectural patterns that are in use here at Made and that Bob made everyone,
267
00:32:07.225 --> 00:32:16.890
have a crack at is that they really enable this this test pyramid by using these patterns where you can actually divorce your domain model completely from from the infrastructure,
268
00:32:18.545 --> 00:32:21.605
by even maybe building a service layer to capture
269
00:32:21.905 --> 00:32:23.365
some of those kind of controller
270
00:32:23.665 --> 00:32:24.485
use cases,
271
00:32:24.945 --> 00:32:26.485
orchestration types of pieces,
272
00:32:27.025 --> 00:32:31.310
I can actually write unit tests for a vast amount of my application totally independently
273
00:32:31.850 --> 00:32:35.630
of the storage system or the specific presentation system
274
00:32:36.225 --> 00:32:38.465
the the specific boundaries at the edge of my,
275
00:32:39.025 --> 00:32:50.230
of my application. And it's it's very similar to what Gary Bernhardt called functional core imperative shell of trying to have the boundaries of your system be as as thin as possible,
276
00:32:50.610 --> 00:32:54.070
and you write them, you know, using whatever style you need.
277
00:32:54.414 --> 00:33:08.179
And you can test them with integration tests or maybe not at all. And then having the core of the application being functional, having no dependencies where you can test it with just data in and data out. And so so beyond just kind of these buzzwords, functional core imperative shell, hexagonal architecture,
278
00:33:08.640 --> 00:33:16.365
test pyramid, like, actually seeing them in practice. Right. Oh, okay. If I build my application like this, it really can work. I really have can have a ratio
279
00:33:16.825 --> 00:33:17.865
of, you know,
280
00:33:18.345 --> 00:33:22.924
10 to 2 to 1, unit test to integration test to to end to end tests,
281
00:33:23.510 --> 00:33:37.875
has been really eye opening. And that's that's something that I've been excited to to share with the world through, you know, the best way I know how, which is writing another book about it, like you're saying. And so at this point, I'm sure that there are at least some people who have decided that it's worth exploring
282
00:33:38.175 --> 00:33:41.875
domain driven design and trying to incorporate it into their projects.
283
00:33:42.220 --> 00:33:43.440
And so I'm wondering
284
00:33:44.140 --> 00:33:50.080
what your advice is as far as next steps for actually getting involved in DDD,
285
00:33:50.540 --> 00:33:51.360
and particularly
286
00:33:52.125 --> 00:33:57.985
when they're trying to implement it on top of an already existing code base where they might need to refactor or rearchitect?
287
00:33:58.445 --> 00:34:00.720
Yeah. Yeah. I don't have any lovely,
288
00:34:01.120 --> 00:34:03.140
answers to the, like, how do I refactor
289
00:34:03.520 --> 00:34:04.820
to get there from here?
290
00:34:05.600 --> 00:34:15.714
So let me just try and treat treat the question separately. The first 1 is about like, oh, listen. I think well done, Harry. You've convinced me that this DDD thing is at least worth looking into. Where can I find out more?
291
00:34:16.335 --> 00:34:18.770
So, yeah, by all means, there's my book.
292
00:34:19.490 --> 00:34:23.590
At some point, we should be publishing an early release on Safari. So that will be public.
293
00:34:23.890 --> 00:34:25.935
And then you can have a look at the sources
294
00:34:26.655 --> 00:34:41.765
on GitHub. We can share that after the show. Sure. And that's a nice lightweight and Python based introduction. Then there's classic books on DDD. I refer them on my blog. That's beta testing goat dot com. So the last post has a a couple of links to books you can read. Now the classic books is massive.
295
00:34:43.125 --> 00:34:50.025
So called blue book, which is Eric Evans, the kind of original proponent of these ideas, is 600 pages long. I've read about 60% of it.
296
00:34:50.720 --> 00:34:56.260
Everyone says it's incredibly dense. It's not incredibly dense. It's not impossible but, like, there's a lot to it.
297
00:34:56.960 --> 00:35:00.205
And so that's that's the way to go if you wanna go in with both feet.
298
00:35:00.685 --> 00:35:02.785
And then the other thing to do is is, you know,
299
00:35:03.165 --> 00:35:03.905
start looking.
300
00:35:04.285 --> 00:35:05.905
There are DDD conferences,
301
00:35:06.925 --> 00:35:12.220
and start maybe watching a couple of conference talks. It's been so refreshing for me having been going to Python conferences
302
00:35:12.760 --> 00:35:13.580
and a few
303
00:35:14.040 --> 00:35:15.180
open source conferences
304
00:35:15.640 --> 00:35:19.714
to go to a new kind of conference where people are talking about software architecture and design.
305
00:35:20.415 --> 00:35:25.555
And they have all kinds of solutions to problems that we run into all the time that somehow we never seem to talk about
306
00:35:26.350 --> 00:35:30.450
in the in the Python world or in the in the kind of Linux y world sometimes.
307
00:35:30.830 --> 00:35:31.570
And so
308
00:35:31.870 --> 00:35:36.050
once people do start going down the road of paying more attention to
309
00:35:36.575 --> 00:35:37.395
the ideas
310
00:35:37.775 --> 00:35:39.075
of application architecture
311
00:35:39.535 --> 00:35:41.715
and maybe using domain driven design
312
00:35:42.175 --> 00:35:44.090
in their projects, I'm wondering
313
00:35:44.630 --> 00:35:46.170
in terms of your experience,
314
00:35:46.630 --> 00:35:53.335
both as far as the projects that you've been involved with and also just talking to other people who are using similar approaches.
315
00:35:54.275 --> 00:35:56.855
Who's responsible for actually implementing
316
00:35:57.155 --> 00:35:58.855
and adhering to these different
317
00:35:59.155 --> 00:36:09.620
architectural principles and designs? Is it just that you have somebody who's got the architect's title, and they are the ones who have to be responsible for all of that? Is it just the individual developer?
318
00:36:10.080 --> 00:36:10.160
Just
319
00:36:11.045 --> 00:36:20.590
what are some sort of best practices from an organizational perspective to keep everybody on the same page? Yeah. Well and I wanna, like, this is obviously something that's gonna be really,
320
00:36:21.850 --> 00:36:24.350
specific to everyone's case. You know, like a
321
00:36:24.730 --> 00:36:26.975
a a 3 person startup is gonna be very
322
00:36:27.535 --> 00:36:37.360
different to a company like Made with a 100 developers. It's gonna be different to a bigger 1. At Made, we're lucky that that we have an architect who knows how to do these things, who came along, was very credible,
323
00:36:37.660 --> 00:36:41.040
was a really lovely person, and was able to sort of show people,
324
00:36:41.420 --> 00:36:45.265
you know, these patterns, why they work, why they're a good idea, try them in real
325
00:36:45.825 --> 00:36:53.525
life, and then, you know, from experience, people are able to say, okay, this really works. Let's do it everywhere. So he was able to to bring things along and be a kind of mentor and coach.
326
00:36:53.984 --> 00:37:01.260
So that's great. And if your company has an architect that already knows these things, you know, go ahead and listen to them and and see if they're convincing in your use case. But I think it's it's
327
00:37:01.900 --> 00:37:10.535
you you know, it'd be quite dangerous to have a team in which there was just 1 developer who's obsessed with this stuff and was just gonna do it on their own. Everybody else is just gonna be baffled because
328
00:37:10.870 --> 00:37:20.250
there is jargon here. And to a newcomer, it's confusing. Like, what is NNT? What is a value object? What is a domain service? These are all things that have meaning. And once you know them,
329
00:37:20.550 --> 00:37:38.670
it's it's a it's a very good language for talking about code. But if you don't know them, it's just confusing and you're gonna ascribe meanings to things that aren't exactly what they are and you're gonna get very confused. So I would suggest it's something that you have to try and adopt as a team and and and find your resources for it wherever you can to try and try and do that altogether.
330
00:37:39.375 --> 00:37:51.050
But the good thing is once you do, it's very powerful because you do have this shared language. In the same way as you have a ubiquitous language for talking to the business about their requirements and how the application should grow, you have a shared language
331
00:37:51.350 --> 00:38:03.464
to use with your colleagues about, you know, the application's architecture, what we how we describe the moving parts and where we put code. So these ideas like domain service or entity or aggregate will have meaning,
332
00:38:03.765 --> 00:38:10.230
for everyone. And then if you suddenly start hiring a bunch of Java developers or whatever it is, they'll show up at the codebase.
333
00:38:10.690 --> 00:38:18.955
They'll, be confused by Python for 3 or 4 days and then they'll get it because Python is so wonderful. And when they see things like entity aggregate
334
00:38:19.255 --> 00:38:20.395
repository pattern,
335
00:38:20.775 --> 00:38:24.400
they'll go, okay, yeah, I know these things because we've used them before.
336
00:38:25.180 --> 00:38:28.160
So that's a team dynamic that's valuable as well.
337
00:38:28.540 --> 00:38:32.275
I hope that answers the question. Yeah. So if you have experts, listen to them and obviously
338
00:38:32.735 --> 00:38:53.175
you've got to build some consensus around it and then the advantage of having a sort of shared jargon. Yeah. I definitely think that that's useful because, as you said, particularly in the case where you maybe have 1 developer who is very enthusiastic and says, I'm just gonna do it all, and then everybody else is gonna have to follow in my footsteps. It's just it's it's not gonna end out well. It's something that requires buy in from everybody and
339
00:38:53.475 --> 00:38:55.255
is a collaborative effort where
340
00:38:55.640 --> 00:39:11.325
you might have 1 person who's maybe driving the vision. Everybody needs to be onboard and interested and engaged with actually implementing those details and holding themselves and their teammates accountable for ensuring that they are adhering to the sort of agreed upon designs.
341
00:39:11.790 --> 00:39:23.385
Yeah. Right. And so you were saying, how do I how do I you know, I've got an existing application. How do I get there from here? 1 classic way is, you know, splitting out a small part of your ModernaF and deciding to build it into some kind of microservice.
342
00:39:23.845 --> 00:39:32.620
And that might be a really nice testing ground for saying, okay, rather than building this just the way we've built everything else, you know, maybe this is a place to go and use some of these architectural patterns.
343
00:39:32.920 --> 00:39:35.500
And if it is if it truly is a microservice,
344
00:39:35.800 --> 00:39:38.525
some of those architectural patterns might be overkill. But
345
00:39:38.825 --> 00:39:50.435
you have a nice controlled design environment for practicing them and you can at least start to get a feeling for the code, how it all hangs together, and have conversations together so that when you, you know, next time you pick off a bigger piece, you've got some knowledge. So, you know,
346
00:39:50.995 --> 00:39:53.335
it's the same way as I would tell people to try out TDD
347
00:39:53.635 --> 00:39:54.135
is
348
00:39:54.595 --> 00:39:55.415
pick a project
349
00:39:56.115 --> 00:39:57.655
of a sort of like contained
350
00:39:58.195 --> 00:40:15.655
experiment where you have, you know, timebox where you can say, well, we're gonna try it. We're gonna try it for this many months, not 3 weeks, but we're gonna try it for a few months, really get to learn it, and really see how it works in this organization. I think it's probably the same kind of approach would work well for for taking on DDD and taking on some new architectural patterns.
351
00:40:16.035 --> 00:40:17.734
And in terms of just overall
352
00:40:18.260 --> 00:40:20.680
trends in system design and application architecture
353
00:40:21.220 --> 00:40:22.600
or just overall influences
354
00:40:23.140 --> 00:40:24.360
from the technology
355
00:40:28.392 --> 00:40:28.892
I'm
356
00:40:32.070 --> 00:40:50.400
I'm wondering what are some of the ones that you are keeping an eye on that you're excited for and some of the ones that you think are potentially going to have maybe a negative impact on the ways that people design and implement their projects? Alright. 2 things, I guess, come to mind there is talking about event driven architectures and talking about,
357
00:40:50.720 --> 00:40:52.260
serverless versus Kubernetes.
358
00:40:52.640 --> 00:40:57.059
So the the the thing we haven't really spoken about today is is this idea of event driven
359
00:40:57.440 --> 00:40:57.940
architectures.
360
00:40:58.480 --> 00:40:58.980
And
361
00:40:59.285 --> 00:41:02.825
1 of the things that happens at MADE is that you have microservices
362
00:41:03.125 --> 00:41:04.985
or at least several different services.
363
00:41:05.685 --> 00:41:06.829
And 1 of the patterns
364
00:41:07.290 --> 00:41:15.765
that, you know, so once you've built your microservices, you've gotta decide how they will talk to each other. And the classic way is they all expose APIs and they can talk to each other over those APIs.
365
00:41:16.385 --> 00:41:18.965
And the other 1 is to have kind of some kind of message bus,
366
00:41:19.825 --> 00:41:22.520
and I've seen that be very successful here.
367
00:41:23.540 --> 00:41:31.655
So that's definitely something to look into if you're if you're working in microservices and you haven't or or you haven't fully decided how they're all gonna talk to each other,
368
00:41:32.035 --> 00:41:35.415
investigate the idea of of a message bus of of asynchronous
369
00:41:35.795 --> 00:41:37.974
event driven communication between your services,
370
00:41:38.515 --> 00:41:40.670
because that that can work really well.
371
00:41:42.650 --> 00:41:45.150
And then 1 of the talks I saw,
372
00:41:45.530 --> 00:41:46.750
a couple of weeks ago,
373
00:41:48.330 --> 00:41:53.295
sort of convinced me that there's there's there really is maybe something to this idea of serverless
374
00:41:53.995 --> 00:41:54.495
where,
375
00:41:54.875 --> 00:41:56.895
you know, even sitting around
376
00:41:57.580 --> 00:42:02.320
having Kubernetes, which gives us this great abstraction and and way of orchestrating and managing containers,
377
00:42:03.260 --> 00:42:06.560
may be still worrying about a lower level of detail
378
00:42:07.085 --> 00:42:08.285
than we need to. And,
379
00:42:09.404 --> 00:42:14.305
and so that's just on a personal level. It's made me slightly more open to the idea that that serverless,
380
00:42:14.605 --> 00:42:16.530
whether it's AWS Lambda or whoever,
381
00:42:16.830 --> 00:42:17.330
is
382
00:42:17.870 --> 00:42:21.970
perhaps more than just a buzzword and the and the fad of the month, but maybe
383
00:42:22.515 --> 00:42:23.975
maybe something quite
384
00:42:24.835 --> 00:42:27.895
interesting about the way we're gonna build applications for the future.
385
00:42:28.515 --> 00:42:34.660
So, yeah. You know, you can tell I haven't really looked into that, but that is certainly something I'm intrigued by.
386
00:42:35.600 --> 00:42:39.845
Yeah. Serverless in general is something that I was skeptical about for a while,
387
00:42:40.224 --> 00:42:44.325
but I actually had the privilege of speaking with a gentleman,
388
00:42:44.785 --> 00:42:54.690
who has founded and built the company, Data Coral, on a couple of recent episodes. And he has actually built his entire platform on serverless technology. So it's definitely interesting
389
00:42:55.155 --> 00:42:57.415
hearing his experiences about the
390
00:42:57.715 --> 00:43:16.105
ways that it has enabled him to approach a different way of building and deploying a SaaS application. So, I'll add links to the show notes for anybody who's interested in following up on that as well. But, yeah, it it it's definitely something that comes with a lot of hype, and I think a lot of people are
391
00:43:16.725 --> 00:43:18.265
probably getting a bit overenthusiastic
392
00:43:18.645 --> 00:43:22.185
about it. But there are some real world use cases where it can actually be beneficial
393
00:43:22.485 --> 00:43:44.579
and enable some different ways of designing and delivering applications. Right. What's the classic Gartner hype cycle thing wherein the the the there's the the something of over inflated ex but the peak of inflated expectations and the trough of disillusionment. So maybe we've both been through the trough of disillusionment and we're now into the plateau of whatever it's called productivity,
394
00:43:44.880 --> 00:43:46.579
plateau of blah blah
395
00:43:46.960 --> 00:43:48.019
blah plateau of
396
00:43:48.400 --> 00:43:49.335
delivering shareholder value.
397
00:43:58.375 --> 00:43:58.875
In
398
00:43:59.230 --> 00:44:05.090
in general in that field that you are keeping an eye on that we didn't discuss yet that you'd like to cover before we close out the show?
399
00:44:05.470 --> 00:44:08.675
Yeah. No. I don't know. Just I'm interested to see how how,
400
00:44:09.055 --> 00:44:14.940
well it it starts to penetrate the the Python world. So I'm talking about it, but I'm not the only person. There's
401
00:44:15.660 --> 00:44:18.640
An Italian called Leonardo Giordani has written a book in English,
402
00:44:19.020 --> 00:44:27.325
in perfectly good English, called The Clean Architecture in Python, which is talking about some of these application architecture patterns very closely related to what I'm talking about
403
00:44:27.705 --> 00:44:29.484
in my book. There's a
404
00:44:29.785 --> 00:44:32.205
bunch of crazy Russians have built a framework
405
00:44:32.670 --> 00:44:33.730
called dry Python,
406
00:44:34.110 --> 00:44:35.010
d r y.
407
00:44:36.030 --> 00:44:40.370
And they have got their own view and a series of abstractions and toolkits
408
00:44:40.905 --> 00:44:41.485
for building,
409
00:44:41.945 --> 00:45:00.535
you know, for for application architecture. And that again is kind of closely related to DDD. So it's, you know, like I when I set out on this book, I did think a little bit, you know, is is no 1 gonna care about this? Is maybe the Python world not doing the kinds of applications that need this? And it's been really nice actually building having these conversations,
410
00:45:00.915 --> 00:45:03.255
meeting Python people at DDD Conferences,
411
00:45:03.635 --> 00:45:04.855
talking to people at PyCon
412
00:45:05.155 --> 00:45:07.255
who are expressing an interest. And I think, yes,
413
00:45:08.260 --> 00:45:10.840
as a community, we're starting to see the level of maturity
414
00:45:12.020 --> 00:45:21.865
in the applications that we're working on, that these kind of problems really are gonna start paying off. So it's, it's it's a nice place to be in. I'm really excited about it. And
415
00:45:22.165 --> 00:45:23.385
so as you mentioned,
416
00:45:23.765 --> 00:45:31.010
the Python community in general hasn't really latched onto a lot of these ideas until somewhat recently because
417
00:45:31.550 --> 00:45:37.075
I think partly because of the fact that it is so easy to get up and running and get something functional and usable.
418
00:45:37.615 --> 00:45:39.954
And because of the features
419
00:45:40.335 --> 00:45:43.474
of the language and the sort of ease of onboarding,
420
00:45:44.000 --> 00:45:45.620
it's become possible to
421
00:45:46.080 --> 00:45:47.860
maybe extend some of these applications
422
00:45:48.400 --> 00:45:56.975
beyond where if you were trying to implement them in a similar language, you would have run into the point where starts to crumble and fall over because of just the difficulty of
423
00:45:57.275 --> 00:46:17.855
contorting your logic into these various shapes. And so I think that now we're starting to run up against the limitations of the Python language for being able to evolve to larger and more complicated architectures. And, also, the fact that Python is starting to make its way into some of these bigger organizations and larger applications. So things like Instagram is 1 of the,
424
00:46:19.559 --> 00:46:29.545
1 of the examples that get that gets, put forward as well as Dropbox. And, you know, some of these businesses that started small with Python have grown to the point where they actually need to be thinking about these more complex,
425
00:46:30.645 --> 00:46:39.210
architectures and design patterns design patterns. Absolutely. And Made is in that case. This is the company that was, you know, just a little a a PHP PHP shopping cart,
426
00:46:39.990 --> 00:46:41.590
with a bunch of furniture on it,
427
00:46:42.070 --> 00:46:47.135
and probably about 12 employees. And over the course of 7 years has grown to like 500 people and,
428
00:46:48.175 --> 00:46:50.655
hundreds of thousands of orders a month. So
429
00:46:51.135 --> 00:46:51.955
and still Python
430
00:46:52.495 --> 00:47:03.540
for the whole of their everything after the shopping cart is all Python here. And so that's grown from, like, let's hack it together and do our best to to something much more, I guess, enterprise y.
431
00:47:03.920 --> 00:47:16.410
And yeah, I think you're right that that some of the the flexibilities of Python has helped. And I think just as as the language grows in popularity, we're just gonna see more and more big things. So what I'm really excited to do is see if we can actually make these patterns
432
00:47:16.950 --> 00:47:17.450
Pythonic.
433
00:47:17.829 --> 00:47:25.355
Because if you ever read a book on architecture patterns, all the examples are in Java or c plus plus or c sharp. And
434
00:47:25.735 --> 00:47:31.335
if you haven't done Java or c plus plus since university or indeed ever, I mean, they're just they're just,
435
00:47:32.730 --> 00:47:40.829
eye bleeding, you know, like, you just read them and you kind of lose interest after the 15th reserve keyword for saying public static void int type main,
436
00:47:41.210 --> 00:47:49.615
all this stuff, which is, you know, yeah, fine. It's a nice way of structuring object oriented code. But when you're used to Python, it just says, here's a function, here's its arguments,
437
00:47:49.995 --> 00:48:07.070
forget your type hints and what's, you know, and public and private. And, like, this is just the core of the code in the most terse way. You know, reading this Java code is is is tiring. And I wonder if there is similarly, like, 1 of my hopes I I haven't quite decided on the title of the book, but I was thinking of something like lightweight application
438
00:48:07.530 --> 00:48:15.445
architecture patterns or Pythonic application architecture patterns because I'm keen to show that, you know, just because you're adopting kind of Java reenterprise
439
00:48:16.465 --> 00:48:39.625
y application architecture patterns doesn't mean that your code base is suddenly gonna gonna look like Java. And so, I'm really keen, especially now while the book is still in draft, to get people's feedback and to see, you know, like what feels heavyweight, what feels lightweight, what feels Pythonic, what doesn't, and see if we can really, as a community, build kind of the Python way of doing these things. Because I think that's something we're so good at is is kind of building conventions,
440
00:48:40.565 --> 00:48:41.385
and deciding,
441
00:48:41.770 --> 00:48:42.510
like, altogether,
442
00:48:42.970 --> 00:48:49.615
you know, this is the Python way that we do things. Like, by convention, no 1 is forcing you, but by convention, we just use underscores and not camel case.
443
00:48:50.415 --> 00:48:53.395
And similarly, I think we can maybe build some conventions
444
00:48:54.415 --> 00:49:08.785
around application architecture, around some of these classic patterns, around maybe type hints as well, whether or not there's something that needs to come into it. Around you were talking about dependency injection. What's the most light weight, Pythonic way of doing it? Do we even need it at all?
445
00:49:09.805 --> 00:49:30.055
I really would like to see sort of more and more people join that conversation. And I think I'm looking forward to the kinds of solutions we're gonna come up with together, not just me and Bob in our book or or, you know, or not just the first draft of what me and Bob have in our book. Yeah. And I'll definitely add links in the show notes to people who want to read through the book in its current state and provide feedback and
446
00:49:30.515 --> 00:49:39.720
start experimenting with the ideas there. And I'm also in wondering if you know of any examples of open source or visible applications
447
00:49:40.100 --> 00:50:01.895
that are using the DDD approach and some of these patterns that we've talked about that people can look at as a reference to try and learn from or get involved with? Yeah. No. I'm afraid I don't have a good answer for that beyond the beyond the 1 I've written in the book and then a couple of other blog posts I've linked to. I don't have a good example of an open source application that's using DDD in that way. I think I think because, you know, it tends to be
448
00:50:02.275 --> 00:50:02.775
about
449
00:50:03.474 --> 00:50:07.180
modeling a domain with business experts and so it tends to be towards the closed source
450
00:50:08.140 --> 00:50:22.905
world. Alright. Well, for anybody who wants to follow along with you or get in touch, I'll have you add your preferred contact information to the show notes. And so with that, I'm going to move us into the picks. And this week, I'm going to choose a book that I started reading with my kids called Dragon Pearl.
451
00:50:23.289 --> 00:50:27.950
It's from the Rick Riordan publishing imprint, and it's actually a
452
00:50:28.329 --> 00:50:29.150
sci fi,
453
00:50:29.529 --> 00:50:41.000
sort of space faring journey that incorporates some different elements of Korean folklore and mythology. So it's very interesting. I've been enjoying that so far. And so with that, I'll pass it to you, Harry. Do you have any picks this week?
454
00:50:42.020 --> 00:50:50.005
Awesome. Picks. Alright. Well, listen. You know, I have kids as well. So as you probably know from experience, I don't have any spare time to read books
455
00:50:50.464 --> 00:51:00.510
or things like that. But I do know in in my very limited time, I I'll mention 2 things. 1 is that for the second time I'm making my way through a TV show called Tremay,
456
00:51:01.850 --> 00:51:06.684
which is the TV show that David Simon, the creator of The Wire, made just after The Wire.
457
00:51:07.385 --> 00:51:09.405
And it's about the city of New Orleans.
458
00:51:09.865 --> 00:51:18.510
New Orleans in the in the aftermath of, hurricane Katrina. So it's about a city that's been devastated by a national disaster that's trying to rebuild itself. And in my view,
459
00:51:18.810 --> 00:51:25.345
it's it's got everything that made The Wire great and none of that kind of, but it's so much more,
460
00:51:27.165 --> 00:51:37.350
because it's uplifting instead of being just kind of depressing. So in the same way as in The Wire, it's talking about, you know, neighborhoods and characters and and, people from different classes and ethnicities.
461
00:51:37.730 --> 00:51:44.465
And it's talking about problems with corruption and the police and the way that, like, kind of institutions and democracy and government is dysfunctional.
462
00:51:45.965 --> 00:51:53.870
But it's it's it's also, you know, so they're very much like these these really good diagnoses of the social problems and and and political problems of America.
463
00:51:54.330 --> 00:51:56.805
But also, it's set in this amazing town,
464
00:51:57.424 --> 00:51:59.285
called New Orleans, where this the musical
465
00:51:59.664 --> 00:52:04.325
the musical and the culture around music, and the culture of the town itself is so strong
466
00:52:04.890 --> 00:52:10.589
that everyone kind of pulls together or or really just just helps lift the spirit of that whole TV show. And I've
467
00:52:11.130 --> 00:52:13.230
never seen a TV show illustrate so well
468
00:52:13.849 --> 00:52:17.575
the way that, you know, each individual is part of a culture and how that
469
00:52:17.875 --> 00:52:27.690
influences them and their life choices, but how their choices also turn back and contribute back to that community and contribute back to the the culture around them and help build it. I,
470
00:52:28.250 --> 00:52:35.174
you know, like, I I tear up at every show pretty much and and and my whole life since watching it has been been trying to figure out how I can move my family
471
00:52:35.875 --> 00:52:42.589
and my, over to New Orleans and convince my wife that this is gonna be a good idea and that, you know, I promise you, even though it's America, we're not gonna get shot.
472
00:52:43.770 --> 00:52:56.260
But it's a it's a it's a you know, we're getting there. We're getting there. She loves jazz too. So, you know, we've got a chance. The other thing I want oh, so you mentioned a book. Yeah. I'm reading a book called Why We Sleep, which has been absolutely fascinated.
473
00:52:56.960 --> 00:53:02.740
I saw it recommended by Rafael Pianazzo, who's 1 of the contributors on the Pytest framework.
474
00:53:03.445 --> 00:53:13.000
He was really enthusing about it, so much so that I I just thought, you know, no 1 can be this enthusiastic about a book without it being good. So I bought it, and I've not been disappointed. It's an amazing,
475
00:53:13.300 --> 00:53:13.800
nonfiction,
476
00:53:14.500 --> 00:53:15.800
written by a sleep scientist
477
00:53:16.580 --> 00:53:21.984
about, you know, what sleep is, the our best understanding of of how it works and what it does.
478
00:53:22.444 --> 00:53:51.965
And, you know, I'm only sort of 3 or 4 chapters in, and I'm already becoming a sleep bore and and kind of going on about it to my friends and telling them the importance of sleep. But, you know, the the short gist of it is that there is it looks like a massive amount of of the modern world's population is chronically sleep deprived. Like, we are not getting enough sleep. We're, you know, we should be getting about 8 hours a night. And ideally, we should be getting 7 or 8 hours a night and a 20 a minute to an hour long nap in the middle of the day, and none of us are doing that. So as a result, we are sleep deprived. And being sleep deprived
479
00:53:52.505 --> 00:53:53.885
affects you negatively
480
00:53:54.345 --> 00:53:56.480
in pre in every single health
481
00:53:57.119 --> 00:54:05.355
metric that you can think of. It's bad for your heart. It gives you cancer. It shortens your lifespan. It reduces your intelligence. It reduces your motivation.
482
00:54:05.655 --> 00:54:10.475
It reduces your ability to build relationships, to be empathetic, to control your emotions,
483
00:54:11.015 --> 00:54:11.650
to enjoy
484
00:54:12.049 --> 00:54:14.549
life. You know, it reduces your physical and psychological
485
00:54:15.010 --> 00:54:15.510
health,
486
00:54:15.970 --> 00:54:28.055
and that's very measurable. And so fascinating book, like an absolute polemic and a call to arms and saying, and I just make sure that we understand sleep is important. Let's get more of it, and let's try and understand it better. So, yeah, Why We Sleep.
487
00:54:28.595 --> 00:54:38.980
I can't look up the author just now, but, fascinating stuff. Alright. It's definitely something I'll have to take a look at. Well, thank you very much for taking the time today to join me and discuss your experiences
488
00:54:39.359 --> 00:54:39.859
of
489
00:54:40.185 --> 00:54:48.285
working with domain driven design and building with it and, helping us learn more about why we might wanna consider incorporating it into our own applications.
490
00:54:48.860 --> 00:54:57.815
So thank you for all of that, and I hope you enjoy the rest of your day. Such a pleasure being here. I I feel flattered to be on the podcast. Thank you very much to I hope this starts some conversations.
491
00:54:58.275 --> 00:54:59.975
I hope to hear from some of your listeners
492
00:55:00.355 --> 00:55:11.099
and, wishing you all the very best. Lovely day, lovely week, lovely month, lovely rest of the year, happy holidays. It's gonna be a beautiful summer. All this sort of stuff. Yeah. Yeah. Absolutely. Bye to buy it.
493
00:55:11.880 --> 00:55:13.099
Alright. Thank you.