>Not OP but couldn't you split up you project to smaller projects?
My own personal stuff I can do whatever I like with, work stuff I don't have much say over. Could they be split up? Oh, yes. Does it need to be 1 million lines of code? No... I think it could probably be about 1/5th to maybe even 1/10th of that.
But still, even if it's split into microservices or just smaller modules, the aggregate lines of code required to solve the entire business problem is still a great deal larger than will fit into 10 well crafted files. Was just curious the nature of the work that naturally fits into that size.
>This article and only rejects the convoluted architecture approach with design patterns and suggests that you can come up with your own design without using these. It is not arguing that there is no need for architecture at all.
I think this article is great. I took this article to be advocating for taking a good hard look at the problem at hand and really nutting out a solution that fits it well. It doesn't reject design patters, per se, it rejects not properly thinking things through.
> revolving around the idea that the act of coding was the expensive part rather than the application complexity.
I just can’t wrap my head around this idea. If the act of coding isn’t the expensive part, then why should I have to spend so much effort coding and why can’t my effort be focused on the application complexity?
I agree that UML and past visual programming environments weren’t doing a good job of splitting these concepts, but I don’t buy that this means it’s impossible to split this.
> Code splitting can be a nice optimization but it can also be a lot of effort for little gain as it is in our case.
We came to the same conclusion when investigating as well, but because of the structure of our site - we had just a handful of layout primitives that were reused across the site so page splitting had no benefits because every page used the same code anyway.
Still an optimisation to look into if you can benefit from it!
> Architecture is the relationships between systems
I find that somewhat limited. A part of architecture “can be” the relationship between systems. As with anything expressing relationships, representing them using diagrams is helpful. Given the textual nature of our tools, storage and change systems, I like the idea that a diagram is based on code. However, it’s no panacea, as future maintainers still need to understand and learn the syntax and rules of that diagramming code. Can code and diagram changes be automated? I suggest no.
I prefer to think that software architecture is the set of decisions made about how to implement the functional and non-functional requirements of a project.
> The "when possible" in your statement is a caveat large enough to drive a semi through
You are absolutely right. It's a real effort of architecture, and sometimes one of the marks of a great projects.
EDIT (thinking of a bad experience of mine): Sometimes, this compartmentalization is also unnecessary and force the architecture to be far worse, too loosely coupled and hard to follow.
> There was no way to separate the code the way you describe without implementing it twice.
Your mileage may vary but implementing it twice can be the best solution if there was so many dependencies to the platform. You should then document the algorithm and reference this documentation in each implementation so that they don't diverge too much.
That's not always the best solution, thought. There's no silver bullet in this world...
> The most useful architecture might be contextual to your organization's size and structure.
I think this is a huge part of it, the other part is what is the scope of the app? Is it just a crud app that needs to integrate with some billing and auth services, or are you building a true web application with multiple front ends?
> You generally can’t auto-generate useful [architecture diagrams] from code,
The question is: why is this the case?
IMNSHO, the reason is that we don't have a way to express architecture in or as code. Instead, we have to compile the actual architecture of the system into one that is expressible using the call/return architectural style that our programming languages support.
That's a lossy process.
When we can program with actual architectural connectors, auto-generating useful architectural diagrams becomes trivial.
> Is this related to C# having this structure where everything is split into hundreds of csproj files and multiple solutions?
I agree that having lots of projects is a pain in the ass, and projects should be used for organizing code into deployment units not for logical separation. But this isn't a feature of the language just a decision(I believe a poor one) a previous developer on your project made.
> ...you would be lucky if you are free to change the higher level structure of the code without having to dive deeply into the low-level code.
The problem, in my mind, is that code can't be accurately modeled on one axis from "low level" to "high level". You can slice a system in many ways:
- network traffic
- database interactions
- build time dependencies
- run time dependencies
- hardware dependencies
- application level abstractions
...and certainly more. On top of that, the dimensions are not orthogonal. You might need to bump the major version of a library to support a new wire format, for example. Anyway, since there are many ways to slice a project, what is "high level" in on perspective can be "low level" from another. And vice versa.
> it is the exact kind of architectural choice you're saying one should decide on.
While I can't speak to what the OP had in mind, architectural concerns are definitely not inside a function. Even connecting individual functions/procedures barely registers at the smallest, most granular scale of architecture.
Of course, our programming languages for the most part don't let us express architectural concerns...so here we are.
> I dunno, I kind of subscribe to software architecture being like, a set of design decisions that guide the implementation.
I think this is the one mandatory part of software architecture which is giving developers information to help them make their own design decisions without constantly deferring to the authority.
But the exact place where architecture ends and development starts varies a lot.
I like to think that architecture itself decides what is important from the architecture standpoint. If architecture decides a certain low level application detail is important, then it becomes an architecture detail.
In fact, in most organisation architecture controls at the very least some top level design like components, communication patterns, APIs and technology in use.
In some organisation architecture goes as far as individual classes. Not all classes, but maybe classes modelling the domain of the problem especially, if that model is used as a language for multiple project or even implemented as a shared artifact.
I think C4 is suitable for those organisations where architecture is concerned with more low level structure than just listing applications and their integration interfaces.
> So I guess one could ask, why should it be any different in software?
Since the software world does not generally work this way, we could also ask why the architect/brick layer model should be applied in this world. The decider/implementer model might be a common organizing principle in other industries; that does not mean that it's useful to software.
Brick layers cannot manipulate more than small chunks of a building at a time. Software engineers in contrast can perform the equivalent of turning the Empire State Building on its head.
Software architecture is difficult to get right and too important to leave to one or two senior folks who may or may not have the insight required to make the right decisions.
> When you find out that the architecture is wrong, do you fix it? Or do you just hack it to get the next bit to work?
That's very project and organization dependent. Some projects are short lived prototypes (I'm working on one now) that are for internal use only, so it makes sense to try and get the damn thing finished without worrying too much about architecture.
Other projects are built to last, or have very high quality requirements, so you want to really get the architecture right, even if that means costly rewrites.
Diagrams capture and represent abstract and/or high level concepts. Their goal is to provide a kind of mental map of how specific aspects of a project are organized in order to help developers form their mental models. This means placing the focus on key constructs and downplaying the importance or relevance of other components. There isn't an objective way to provide a one-to-one mapping between what bits of a software project are of critical importance to form mental models, and what bits are irrelevant.
> IMNSHO, the reason is that we don't have a way to express architecture in or as code.
Not true. We have more than plenty of ways to represent software architectures. That is trivial and a solved problem. So is mapping representations of software architectures to (some) source code, at least in the form of skeleton code. The problem lies in mapping software projects to a software architecture, even when the software project is clean and a textbook example of a very specific software architecture.
> It seems like the tradeoffs in the different approaches are all about where the smarts are, and whether you can horizontally scale those smarts. Does that sound accurate?
The real question is whether you are going to ship your code to your data or your data to your code.
> Is your code so tightly coupled between logic and display that you haven't reduced the common features to, essentially, libraries at this point? Separation of concerns is not a novel concept.
No, I don't think many development companies have reduced the common features of codebases in 3 different languages to libraries yet.
Deciding on the architecture of an application based on the org chart is probably not a good idea.
reply