Architectural Patterns & Enterprise Patterns

[AdrianKearns]

Hi,

This resource was pointed out to me by a colleague, it's an excellent resource, great job. I humbly offer the following as constructive feedback - very happy to discuss.

I wanted to offer some comments, specifically stages 8 & 9, Architectural Patterns & Enterprise Patterns:

1. I don't think the arch and ent arch patterns you mention are really that different - they are all just patterns. So I don't see why you'd distinguish between them. I think its particularly problematic as a resource for aspiring architects who will already be navigation quite a lot.
2. Obviously the patterns listed are not an authoritative list - which is fine, maybe mention that.
3. Use Cases isn't a pattern - at least not that I am aware of.
4. Domain Driven Design is a method / approach, not a pattern.
5. ORM's hmmm, more of a technical solution type / approach to data access. I guess it's "architecty" but I'm not convinced it's a slam-dunk for an architecture pattern.
6. If you wanted more architectural styles, REST would be an obvious one to add, as would microservices.

When you say Software design & architect - are you meaning software architect as opposed to solution architect?

I also wonder if there's a case for putting architectural patterns ahead of styles? If the general idea is to introduce increasingly complex ideas, or ideas that build on the previous ones, then patterns would more naturally fit before styles in my view. Any develop that understands design patterns in the coding sense will have no issue understanding them in the architectural sense; styles is a bit different though - more open-ended and requiring interpretation.

There's other topics which might be options to include, but I'm not sure how you'd classify them. Stuff like the 4+1 model, and the "Views & Perspectives" approach to thinking about and defining architectures.

Best Regards,
Adrian

https://morphological.wordpress.com/

[stemmlerjs]

Hey @AdrianKearns, thanks for your comments. I'm going to roll back around to this and update the entire thing once I'm finished writing my book. I fundamentally agree with most of your comments.

The goal with this is to get people familiar with REST and MVC to recalibrate and approach software design as more than just typing. I initially wanted to explain this as "levels/layers of design", but that's not incredibly helpful.

With respect to architecture, the goal is to show people which architectures exist as solutions to non-functional requirements, similar to how design patterns are solutions to common class-level problems.

I have a plan for this. I'm going to update this to be more in line with what I'm writing about in solidbook.io and raise testing as a primary concern.

[stemmlerjs]

Quick update for everyone reading this: This roadmap is changing drastically as I'm nearing the end of writing solidbook.io.

The actual title is:

solidbook: How to Master The Essentials of Software Design & Architecture, Build Scalable Applications, and Become a Software Crafter

The goal?

Help coders become crafters. Learn the mindsets, essential principles, practices, and patterns employed by The Phronimos Developers for decades in writing scalable, professional software.

After 4 years of reading, writing, coding, and teaching, the actual roadmap has changed a ton. It primarily focuses on moving you up the Phases of Craftship and learning what I call The Essentials first.

Phase 0: Non-Coder means you're still trying to learn to code, so you're not quite yet in the software design and architecture journey.

Phase 1: Coder is when you finally enter the journey, but you have many problems. Code gets worse instead of better; your projects get large and messy, they're hard to finish, requirements get missed, you spend a lot of time debugging, there are few to zero tests, etc.

The biggest issue at this stage is, above everything - mindset. You go from requirements → code. And that's where many of the problems stem from.

In the final Phase of Craftship - Crafter (I call it), you go from requirements → domain → features → high-level design → tests → code → refactoring & low-level-design.

There is a lot involved in each step of the transformation process.

This is ultimately what the roadmap entails.

It's a mixture of mindset, principles, patterns, practices, and skills.

To keep up with the progress, join the community discord via the #solidbook-chat channel.

I'm working on the final table of contents this week.