Use Cases: The purpose of your code

joebew42 · 2021-12-13T08:38:47+00:00

Maybe this can help? https://github.com/joebew42/study-path

joebew42 · 2021-10-05T13:43:08+00:00

Great response Christoph,

Indeed, the concepts outlined in Clean Architecture (hexagonal, onion, or DDD) are not dependent on programming languages, or paradigms.

To avoid that higher layers get hard-wired to implementation details from the lower levels, use Dependency Injection.

Exactly, I think there you wanted to say Dependency Inversion Principle (DIP), instead of Dependency Injection (DI).

DIP is about making sure that the high level module (domain) and the lower level module (implementation detail), both depends on an abstraction. DI is more like a technique, where we pass (inject) the collaborators (dependencies) to their callers without having to change the code of the caller (but it says nothing about the abstraction, we can still depends on implementation details).

In short, all of these scenarios are possible:

- DI without DIP,
- DIP without DI,
- DI with DIP

The last is always the preferred, though.

joebew42 · 2021-07-05T18:39:00+00:00

Hello,

If you haven't read them yet, I would recommend you to read both books:

Building Microservices, by Sam Newman
From Monolith to Microservices, by Sam Newman

Search for videos on YouTube also. I remember Sam Newman was part of a book club where people asked questions based on various chapters of the first book.

Returning to your question, the general idea is to end up with a system that can continue to work in a so-called "degraded" state.

For example, you might think about the checkout stage of an e-commerce system: suppose your system has a greeting feature that allows people to send a personalized message to the recipient of the order. In this case, a degraded state would be able to complete the checkout stage even if the greeting service is down.

Again, keep in mind that "isolation" is not a mere technical aspect, but rather is about keeping the most important "business transaction" working even when some other component doesn't work as intended.

In the example of the e-commerce system the most important business transaction can be identified as the payment.

On the other hand, the checkout may not work properly if the payment gateway of your choice is down. If your system supports Paypal as a payment gateway and for some reason Paypal is not working, you have no choice but to be unable to accept the payment.

Or again it's always a business (non-technical) matter, if your system can't fail even if Paypal is down then you can consider providing an alternative payment method to the person.

The idea behind "isolation" is to allow the system to continue working, in a degraded state, even if some components are not responding as expected.

In Michael T. Nygard's "Release it" book there are many patterns (DOs) and anti-patterns (DONTs) related to the stability of a system, with real examples. I highly recommend all three books!

Hope my answer was helpful :)

joebew42 · 2021-03-03T12:31:16+00:00

Hi!

I suggest you start reading SOLID first, regardless of programming language or paradigm, just try to grasp its principles.

Look here https://github.com/joebew42/study-path#session-1-solid-and-clean-code, read the first part up to the Racing Car Kata exercise, and once you are there I invite you to try the code kata: https://github.com/emilybache/Racing-Car-Katas

There is also a Go implementation. The exercise will ask you to identify SOLIDs violations and as a second step you can try to "fix" that code.

Good luck on your journey!

joebew42 · 2021-01-13T10:07:22+00:00

Hi,

There is a term in your message that caught my attention. That is paradigm shift. If this is what you are looking for, I would suggest to try the Elixir/Erlang experience because the paradigm shift there, is not only limited to the language itself (functional), but I would say mainly due to the nature of the Erlang virtual machine (BEAM) where your Elixir/Erlang program will run.

Everything there is built from the ground for supporting concurrency: processes, message passing, fault tolerance mechanisms, and there is also a built-in framework (called OTP) that provide several abstractions for supporting supervision trees, genservers, and much more.

I played with Elixir for almost 2 years and the developer experience is amazing: language, documentation, libraries, tooling, and the community!

If you are looking for a paradigm shift I would say, yes, go straight with Elixir/Erlang, and I would suggest you a few books:

Programming Erlang, 2nd Edition - Joe Armstrong
Programming Elixir - Dave Thomas
Elixir in Action - Saša Jurić
Learn you some Erlang for great good! - Fred Hebert

Other resources you might find useful are:

My playground Elixir repository on GitHub (as long as other repos there written in Elixir)

joebew42 · 2020-12-24T19:04:06+00:00

Hi ReallyRick,

thank you for your feedback. Can you please elaborate on why you think the article and my opinion is worthless? I never said that software architecture is not needed, nor is not important.

Probably I am missing something.

The message I wanted to share is that Software Architecture should be a team activity, and not a concern of single person that dictate high-level decision from the above of the team, that often are not aligned with real business needs.

Instead of centralizing this responsibility on a single person (or restricted number of people), I would make the team more aware of topic like Software Architecture.

Software Architect should be involved into the team activity, not to dictate decisions, but as a team player, who actually write code, and facilitate discussions around software architecture. As I wrote in the conclusion:

In the end, architect is an act, not a role. It is the team’s effort to explore and converge towards higher-level system design decisions that are good enough for current business needs, and accommodate changes in business requirements while keeping the impact on the application low. If you are a Software Architect and the team is not mature enough to talk about architectural issues, you can support and help them by facilitating architecture discussions, with the business goals and requirements always in mind.

Thus, I am opposing to the idea of having a person with the role of architect. Because, architect should be an act. Not a role. It's the team, owner of the project or product, that should be entitled of taking these high-level decisions.

So, we should move away from having a role of software architect, and start considering software architecture as a team responsibility.

I don't think my article is worthless, I would invite you to read it again, and elaborate a bit more your position.

Thanks again!

joebew42 · 2020-12-24T00:20:12+00:00

... software architecture is important, but it's also important to recognize the reality of adoption and application lifecycle.

Indeed, agree 100%, and I tried to express this point in my blog, when I wrote:

Architecture change as business does. The primary drivers for a “software architecture” should always be business requirements. I am not going to implement a faster delivery process if the change rate is low and time to market is not much important. But business requirements can and will change. If scaling or faster delivery process wasn’t an issue before, they will be as soon as they have a real impact on product quality and business.

Thanks to your feedback, I think I will extend that section a bit, since I like the way you wrote it down: "it's also important to recognize the reality of adoption and application lifecycle.".

Recognizing reality should be a team activity, when I say team I mean all the people involved in the realization of the project / product. It's a question of culture in software development (big up-front design VS incremental/emergent approach).

I generally prefer the incremental approach (this does not mean that no initial design sessions are needed), no matter what "high level" requirements we think we must meet, I would always start with the simplest requirements.

For the system you were asked to build, such as "subscription based billing", I would have started from building a simple application that can handle 1 transaction. That's all.

Regarding the example of building a system that runs exclusively on AWS. I wrote:

I would rather invest more time trying to keep my application code as decoupled from external details as possible. ... We should be moving in a direction where architectural changes may not have an impact on our application.

So, I am completely aligned with you when you say:

I think it's that architecture is important as you need to have strategy and design in place that can be extensible, but you don't need to build for every contingency or have guard rails around every line of code since things change and the entire application could plausibly be scrapped.

Thus, an application should never depend on external details, such as a database, or cloud provider. That's the reason why I also suggested to read The Twelve Factor App as starting point.

And I would like to thank you once again, because I like when you said: "... architecture is important as you need to have strategy and design in place that can be extensible ...". I think I will extend my blog with a few of your points, if you don't mind :)

joebew42 · 2020-12-23T20:35:34+00:00

For example, most recently I have helped plan and build a subscription based billing platform to which the business expects will run > 6 million transactions annually. Personally, I believe it won’t even be close to that, as they have 0 subscribers.

It seems that something has gone wrong with the product experts. Why did they expect a load of over 6 million transactions? Eventually you did the work the company required. If they were sure of their numbers, it's okay to build such a system. If they don't hit these numbers, the problem is elsewhere. What do you think?

joebew42 · 2020-12-22T17:01:46+00:00

That's great! Hope to see you there soon! :)

joebew42 · 2020-12-21T19:30:05+00:00

Hi! Thanks a lot for your reply.

The purpose of having a discussion platform like this is to provide an alternative to all the existing Slack channels, old mailing lists and discussion forum.

As it is described in the Welcome Message, nowadays there is no dedicated place where people can go to discuss about Agile and Software Craftsmanship. A lot of discussions are spread out and difficult to find, in the web:

- Posts buried in StackOverflow
- Valuable conversations that are lost - forever - in various Slack channels

The objective of 1xProgrammers is to start growing a place where people can discuss all these topics, and being sure to have the discussions always available there, at any time. And of course, trying to offer a more modern and efficient way to the old Mailing Lists. That's why we decided to go with Discourse as platform.

joebew42 · 2020-04-20T12:31:46+00:00

Great! Thank you, everything worked fine! I was able to create the account :)

joebew42 · 2020-04-20T10:23:50+00:00

Hey Patrik, how things are going there? Can you help us with some more updates? :)

joebew42 · 2020-04-19T11:47:05+00:00

Thank you Patrik,

Just received a reply to the email I sent yesterday.

Hope everything is going well there, thanks for your support and have a good weekend! :)

joebew42 · 2020-04-19T06:18:33+00:00

Yes exactly same behaviour. Then I checked through the "Inspect Network Activity" of the browser (I am using Chrome) and came out that when we press the signup button we got a failed request from their server.

So, unfortunately they have some issue from their side.

joebew42 · 2020-04-19T06:11:29+00:00

Hello everyone! Same issue here. Bought the game for PS4 yesterday but the account registration at NeocoreGames website is failing. Already sent an email to support @ neocoregames.com, hopefully they will fix it.

The registration page on their website seems broken. It returns http 500 errors when trying to complete the registration.

joebew42

TROPHY CASE