https://serverless-stack.com/ logo
#random
Title
# random
t

thdxr

10/07/2021, 8:12 PM
So in my typescript monorepo I split up code into core and services. Core contains all business logic and services simply call into core. I've been thinking about this more - does this actually make sense or is this a legacy pattern from the non serverless world? If you're all in on serverless, sometimes your business logic is implemented as a step function and splitting that creates a two way dependency. The historical benefit of splitting is so that core functions can be called in a variety of places. For example writing some kind of migration script. But in the serverless world, are local scripts even the right pattern? Most scripts like that are better modelled as step functions and you might as well run everything in the cloud
I still think it makes sense to separate your API functions from core so that no business logic is in your API layer. But in practice I'm starting to not see a lot of benefit otherwise
a

Adrián Mouly

10/07/2021, 8:30 PM
My business logic it’s on packages.
t

thdxr

10/07/2021, 9:00 PM
I guess another way to say it is I've optimized for running code in non AWS contexts. In practice that's just something local, tests or scripts
But maybe all of that should run in aws
t

Thomas Ankcorn

10/07/2021, 9:01 PM
Imo the benefit of splitting is not reusability. it's Independence from your infrastructure layer so you can change things faster and write robust unit tests against your business logic. I struggle with the value of this too. It's a lot of work. I rarely put the effort in. I guess it is more valuable once we have a better understanding of the domain we are working in
I have been reading the domain driven design book by Eric Evens I don't know if it is helping or making the internal dilemma worse
t

thdxr

10/07/2021, 9:08 PM
Yep exactly. This is a pattern from DDD. But with serverless is there still that traditional split between infra and business logic?
I ran into a situation where the best way to implement business logic was to invoke a step function series
And that got me thinking if typical DDD patterns need to be rethought
You can implement really complex business logic with new thew SFN updates
t

Thomas Ankcorn

10/07/2021, 9:30 PM
Is that more because the step function tooling is awkward and doesn't enable good development practices?
Testing step functions has always been a real PITA 😂
t

thdxr

10/07/2021, 9:32 PM
I think I mention SFN because it's a good example. I think more broadly serverless blurs the line between infra and application so I'm starting to feel like the old patterns don't work as well
For example API definition can now be done in infrastructure
t

Thomas Ankcorn

10/07/2021, 9:36 PM
Yeah but wouldn't that stuff always be outside the domain?
t

thdxr

10/07/2021, 9:36 PM
Historically yes. But now it can literally be the implementation of a domain function
Since infra is doing more and more for you
Also another benefit historically of keeping it sperate was to hide infra details from the day to day. But now it's important to understand those details
t

Thomas Ankcorn

10/07/2021, 9:39 PM
But we don't want those infrastructure details to bog down day to day stuff either. I don't really want my application code to know about some of the messed up single table dynamodb stuff
t

thdxr

10/07/2021, 9:41 PM
Domains can still encapsulate things from each other right
t

Thomas Ankcorn

10/07/2021, 9:41 PM
What do you mean by that?
t

thdxr

10/07/2021, 9:44 PM
You can still have domains that hide implementation details from other domains that don't need to know about it. I was mostly thinking about leaving infra code inside domains since they're doing more application like functionality these days
t

Thomas Ankcorn

10/07/2021, 9:52 PM
Ah okay thanks ☺️ It's worth saying I'd say like 60-70% of the code I have written in the past year using serverless is just like inline single file functions
3 Views