Greenfield Project? Start HERE!

If you're starting a new greenfield project, how much effort do you put into the overall architecture and design? What are the types of things you should be considering or thinking of? It's also really applicable if you have an existing system that you might be trying to decompose or rewrite portions. I'm going to talk about aspects critical to the foundational architecture and design, allowing you to evolve your system over time.

🔗 EventStoreDB

💥 Join this channel to get access to a private Discord Server and any source code in my videos.

🔥 Join via Patreon

✔️ Join via YouTube

0:00 Intro
1:32 Size Matters
2:25 Logical Boundaries
6:58 Loose Coupling
8:49 Logical != Physical

#softwarearchitecture #softwaredesign #domaindrivendesign

[CodeOpinion]

I was bound to fail at editing at some point! Shoutout if you stayed to the end to notice it! Good thing I didn't swear!

[marna_li]

Events also give semantics to your code by indicating something happened, often derived from a business process, and you are responding by doing operations. It is easier to navigate and maintain code if you think in terms of events, and not just performing operations.

[coryserratore]

I love the emphasis on boundaries. Software is an abstraction of business processes.
If your software system was a brick and mortar business, how would you divide the responsibilities into floors and departments?
A good org structure is functional and efficient. A poor org structure leads to a dysfunctional and bureaucratic mess of inefficiency and conflict - a turdpile.

[RebelSyntax]

Blank solution -> console app -> starting writing methods and data classes. Let it emerge.

[FlaviusAspra]

Start from an use case and implement it front to back, all of it, for only one stakeholder, who will tell you he's happy with that one use case.

Abide by the best practices in design while doing so. This will help keep the code easy to refactor.

Then tackle the second use case. Refactor as you go.

Do not attempt to make it perfect, because you're bound to make imperfections in the design.

Instead, make it: observable, moldable, decoupled, so that when hard times come, it's easy to sail in a different direction.

You're going to change it, so don't try to reach some notion of perfection. Instead strive to mechanically apply the best principles. Stay away from using SRP as a main argument for anything at the class level, it's most of the time misleading. Use SRP rather at the component level (bundle of many classes) or at the public-method level.

[jakkepiet]

Two of the best examples on language in coding/software design are:
Wat is a book: the printed copy, the script, the title, the revision, ....
In a financial system: what is a transaction.

[marna_li]

I have noticed that some projects gets to rigid by focusing too much on performance at the start, instead of focusing on how to actually design the software. Not saying that you shouldn't think about performance. But once you have something in place you can fine-tune or even swap out stuff as you go. You should experiment and see what is best and not lock yourself into on solution from the beginning. That is easy to do when it is your first big project.

[bobbycrosby]

I'm curious if you have a video about sizing your logical boundaries correctly. I mostly try to size them as small as "reasonable" - reasonable meaning the boundary's logic and data isn't like swiss cheese because it depends on too much data primarily owned by other boundaries.

[awright]

The earlier you are in developing a system, the less you understand about it. If the business that the system is for is also entirely new then then finding the "right" boundaries seems impossible. On the other hand if the system is automating a currently manual process it should be a bit easier to figure out.

[coryserratore]

That event sourcing vs CRUD (and entity-state persistence in general) question triggers me to challenge the status quo assumptions.

It's 2022. Unless you're building an embedded system, data is dirt cheap, so why not start with event sourcing (CQRS/ES, really)?
If you're being agile (lower 'a'), you don't know what queries you'll need to support, so why lock yourself into a more rigid persistence model, such as a relational schema design and O/R mapping - that is not responsive to change - when you pretty much know it will change, and often.

Store events, build materialized views/projections as you uncover query use cases, and benefit from having the flexibility of an event store to tap into for past and current data to build an optimal query and analytical model if/when you need.

A common architecture principle is to defer decisions until they are absolutely required. Then you're making the most informed decisions you can.

[jameswrightson]

IMO seems overkill for a fresh greenfield project, majority of the work you can do should start with a monolith and work up to micro-services when the organizational aspects require it!

[adasit]

at 10:47 we can see error on recorder 😅 that's nice