Greenfield Project? Start HERE!

[@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!

[@daretsuki6988]

It's gold!

[@AidanRIR]

...So how much effort should you put in ... doh! Great video as always thanks for sharing!

[@vbaclasses3553]

I thought it was a KZbin glitch 😅. What a gem.

[@georgehelyar]

At least once delivery

[@rlarno]

😅 The end was a bit, eh disconnected 😂

[@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.

[@coryserratore5951]

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.

[@gabrielverle9469]

these are some valuable tips, I just didn't understand the last part, can you give me examples of how to use SRP at the component level or at the public method level?

[@FlaviusAspra]

@Gabriel Verle at the method level: It should do either just read operations or write operations (with reading the necessary data only) The method should not have side effects other than what it's supposed to do The component level: Works only within one boundary. It does not depend on other higher-level components (direction of dependencies) And most importantly: it deals semantically with only one aspect of the domain model (multiple, related use cases). Example: in an e-commerce domain, you have suppliers of products, and so there is a component "suppliers". The various use cases within this component could be: catalogue import, out ordering, order confirmation Another component is listings: use cases here would be: select best supplier of a product, calculate price of a product, calculate delivery days of a product. The two components, if they need to exchange data, they can do so asynchronously and over value objects only, not sharing any other code. The value objects are owned by the component where the data belongs semantically. Each of these components does only one thing (at a higher level of abstraction): suppliers deals with ingress and egress data from/to suppliers, listings deals with creating and maintaining advantageous listings across these suppliers.

[@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.

[@CodeOpinion]

Interesting, haven't heard the book example before. Thanks

[@jakkepiet]

@@CodeOpinion it is a very useful example, because you can directly link “business owners” to the different concept of a book. Making it understandable for analysts, developers, business owners, stakeholders. And it provides just enough complexity to show the need for a domain language, which you can then showcase in bounded contexts.

[@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.

[@CodeOpinion]

Agree'd. There's this emphasis on scaling and performance that often times isn't required. "We need it to scale to millions of users...". "How many users do you have now?"....."50"

[@marna_li]

@@CodeOpinion Develop for both now and the future by not making it more complex than what you actually need it to be today. Build for refactoring. Perhaps developers forget this because they cannot see themselves maintaining their code in the future. Well. Consultants might actually hand the code over to some maintenance team.

[@bobbycrosby9765]

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.

[@CodeOpinion]

I don't explicitly in a video. Good suggestion for a video!

[@coryserratore5951]

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.

[@CodeOpinion]

Why not start with ES? Skill/Knowledge/Understanding of it come to mind. I'd guess the vast majority of ES systems built that have failed was because of lack of knowledge,

[@coryserratore5951]

Familiarity, for sure, and the unfamiliar is perceived as more complicated, even if it isn't. Entity-state and O/R persistentence has been around a long time. Plenty of framework support abstracts the underlying complexity. I'm seeing more ES support in frameworks, however, which gives me hope the pattern and its benefits will become more familiar, if not the default preference one day.

[@pilotboba]

@@CodeOpinion You could probably say the same about state based storage systems as well. Devs like to hand-wave that the persistence layer is just an implementation detail. While true, you also need to understand your data layer, both physical and logical models. That goes for state based stored, whether relational or document or object or whatever based just like you need to understand event store type storage to use it.

[@nctrn07]

Super informative video as always!

[@CodeOpinion]

Glad you think so!

[@awright18]

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.

[@jameswrightson744]

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!

[@CodeOpinion]

I'm not implying microservices. Hence the part about logical vs physical boundaries.

[@phillipsma]

@@CodeOpinion I think you hit the nail on the head here. Microservice discussions focus too much on the physical deployment and less on the logical. SOA in my opinion is more about alignment of business (and team) capability to a logical boundary, not a physical deployment ownership. The problem that comes with logical alignment is then how to deploy those multiple single-boundary components into multiple physical hosts that make up the system, a problem a microservice seemingly does not have which is probably why it's gained popularity but at the expense of possible coupling due to incorrect logical boundaries.

[@CodeOpinion]

Bingo!

[@ThugLifeModafocah]

Ohhh I see what you did there 😂

[@maxkomarow]

👍

[@adasit]

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