This is a question that I couldn't find an answer to until I came here. How do we communicate designs and code that, I usually use UML (specifically deployment diagram) but frankly speaking there isn't much resources on UML and good examples on Deployment diagrams. If you google UML deployment diagrams you find the same picture of that lame java web app from the 1999 Which proves that very few people are using UML. Martin fowler book (UML Distilled) has exactly 1 page (yes only one page) explaining the deployment UML diagram. I used that to build my architecture diagram for my previous company and even back then I felt it was a bit odd. I like your C4 model in 25:00 .. I might consider using it, zooming in and see more details.
Very good talk. It is more detailed talk about design and layering design (C4) than Olivier Gierke's (Spring Data) and Jakub Nabrdalik's (Allegro - how to fit this in DDD) talk. But the concept is the same. I'm using same approach for 2 years but starting from bounded context (ddd) level and components with isolation using package scope and I can easily say that this works in all projects and when You describe this architecture to juniors, they are beginning to think about architecture.
What I find amusing sometimes is how dogmatic the community can be sometimes when approaching problems (or finding solutions). Our industry developed these practices and patterns through many trials, however, it's always important to ask whether it's suited to the problem at hand. In my opinion, the best thing about the TDD is Dead video referenced in this video was to hear conflicting opinions and having an open mind. I adored hearing how pragmatic Kent Beck was. Also, am a big fan of Jim Coplien as well.
Excellent talk... but the slide at 32:37 has triggered me. I "just about almost" remember "the Fortran days" and when I read on the paper illustrated "Unit testing was a staple of the FORTRAN days" a loud voice is yelling in my head "Was it?!?!" I must admit that I didn't come across the concept of Unit Testing until about 25 years after "the Fortran days".
Very nice talk. I was doing some deep researches about software architecture lately trying to find the one solution. I kinda got to an interesting results anyway. I will definitely share it somewhere once the picture is very clear and when its proven to work well.
Simon has a point and a point of view -- which is plausible. But when you listen to him many times, in separate talks, it feels like he has this pattern of inventing problems on how architecture is done (which includes making faces, sarcasm, shrugs etc. !) to get at how good C4 is. Layered architecture and all those jumbled arch diagrams might have been perfectly useful in some architecture brainstorming session, which we know nothing about. Instead some snapshots of random diagrams are thrown at us in a talk, coupled with how clumsy those are. It is the not-so-fine art of selling !
yes it was mostly bullshit. I saw couple videos today and it is opposite way of how Martin Fowler speaks. Clear and openly explaining his point of view. This guy here speak worst way for technical presentation possible.
Well this was quite interesting, especially the unit testing vs black box testing. You see, I am a self taught programmer and I came to the black box, component style testing naturally. It seemed stupid to me to unit test as I would need to add complexity to my code base in order to test it which added no benefit. Instead I decided that I would build modules, or self contained components consisting of several objects with a public interface and then test that entire component through the public interface. Maybe I'm not as bad at coding as I thought I was then...
No, you are great at coding if you follow this practice! All too often I hear the argument that "unit testing" means you have to test "the smallest unit possible". That is a terribly way to write regression tests. The fallacy is that developers then tend to focus on covering the code with tests, instead of covering the _behavior. When you cover the code, you all too often end up with rigid tests that make it harder to evolve your software. What you describe, with componentizing and testing through the public API is critical, because your public API _is the behavior of your component. To me "unit testing" is equatable to the qualities that your tests have, they should be 100% reliable (must always give the same result if the code hasn't changed), fast to run and fail only when a bug is introduced (testing behavior vs implementation is paramount to this).
> Maybe I'm not as bad at coding as I thought I was then... Whenever I had this thoughts about myself, reality swiftly proved that not only was I as bad as I thought, but even worse than I thought. 😂 But I'm happy for you if you had a better experience.
+1 for a new language where components are first class citizens (or introducing somehow the concept in existing mainstream languages). I agree that it would be a major step toward closing the gap between architecture and code. If we had the ability to control more precisely who can use a given package, we would not lose TDD in the presented C4 model. Indeed, a test package could be given special privileges. This kind of fine-grain package management can be enforced with tooling around the language.
+Loïc Yvonnet All modern languages have this now. Script languages have their package manager. GO and Rust have it too. Not sure about Swift (but i assume not)
Very interesting presentation and I tend to agree with all that was said, but why not go one level below the components and show the layers too. Because end of the day the code does need to be layered, may not be for some simple applications, but for most others.
I actually made a tool to go up and down in architecture. Pinch in and out as the speaker put it. I think it helps to really understand the architecture. The tool does work, but it needs a LOT of improvement to be really useful. It is currently hosted at programwith.us/ but may move in the future. After seeing this talk maybe I’ll get back on that project.
The container/component diagram concept near 25:00 is great, but it only shows the things. What about the messages? I'll have to try C4 on a small scale this weekend and see how it goes.
Great lecture. What I grasped: Analyze and adapt. Until we have all the solutions, we have to think. Architecture Design must reconciliate structure and code merging them and presenting layers of abstraction in a way that works and actually makes sense.
I really appreciate the C4 model of Architecture representation where code reflects the abstractions... Only one area which I'm still trying to figure out where Functional Architecture would be defined? Will it part of Context?
Deja Vu all over again. I think a much more important question should be, in 2014 why should anybody not understand architecture and its relation to code? Because this horse gets flogged by every generation. And that is the key point here. What happens to deep craft knowledge when every four years the number of coders doubles. What happens when it takes at least eight years if not longer to get any good at coding, but the number of skilled coders gets diluted by half every four years. You have to flog the same horse every eight to twelve years. And consultants like you take a simple idea and explain and elaborate it to death in the hopes that the lack of knowledge and experience in the current crop of newbies can be overcome by process and structure. It has yet to work in all the decades I've been in this industry, and I would be surprised if it works now. It will only start working when the population of programmers stops doubling and age and experience can distribute itself along a bell curve just like every other mature engineering discipline.
The best classic software architecture book I can think of is the "Gang of 4 Patterns" book. Since most of good modern architecture documentation is in the context of the web, here is a list of relevant architectural topics to Google: N-Tier, MVC, MVVM, Monolithic Vs Microservice, Event Driven Architecture, SQL vs NoSQL, Domain Driven Design, and Clean Architecture. And no software architecture comment would be complete without a nod to object-oriented vs procedural vs functional!
If tests allow you to refactor easily and is definitely reflect the code, then you have almost all that good architecture should provide you. Yes, it is probably mean that you don't need architecture, or even that you have an architecture of some sort. The only thing missing is pictures, i.e. "common" language for conveying your ideas to the team members and for drawing "a big picture" to choose the direction for refactoring/developing. In a sense your test suite is a big picture of your system, and the main problem that it is a text, a description; and I'm not sure if we've came up with an idea how to generate pictures from books already. By the way, want to notice, that generating architecture pictures from code, as speaker proposes, is still code first approach, still not waterfall. Your code doesn't change according to architecture/design, but your architecture/design changes according to the way you code.
All life forms from bacteria to humans are software driven systems. They all use the same fundamental software architecture that I call an Intelligent System. For a life form to live, grow, and reproduce it needs intelligence made up of many different intelligent systems. All intelligent systems are knowledge based and the system architecture is based on ten fundamental knowledge contexts. The 10 knowledge contexts are Name, Authors, Purpose, Environment, Language, Configuration, Operation, Owners, Market, and Value. All the code is contained in the Operation context. Everything you do in life results of the actions of intelligent systems knowledge software.
I went to a global meetup for programmers and enthusiasts and I barely could enjoy the meeting since almost the entire meeting was about working with TDD. I was totally unrelated and even the software downloads rejected my OS. I hate too many crutches.
jagjit bhatia same here. I use something close to C4 at work. On the other hand it is pathetic anyone would call themselves an architect and not be well versed in UML.
This is a question that I couldn't find an answer to until I came here. How do we communicate designs and code that, I usually use UML (specifically deployment diagram) but frankly speaking there isn't much resources on UML and good examples on Deployment diagrams. If you google UML deployment diagrams you find the same picture of that lame java web app from the 1999 Which proves that very few people are using UML. Martin fowler book (UML Distilled) has exactly 1 page (yes only one page) explaining the deployment UML diagram. I used that to build my architecture diagram for my previous company and even back then I felt it was a bit odd.
I like your C4 model in 25:00 .. I might consider using it, zooming in and see more details.
Very good talk. It is more detailed talk about design and layering design (C4) than Olivier Gierke's (Spring Data) and Jakub Nabrdalik's (Allegro - how to fit this in DDD) talk. But the concept is the same. I'm using same approach for 2 years but starting from bounded context (ddd) level and components with isolation using package scope and I can easily say that this works in all projects and when You describe this architecture to juniors, they are beginning to think about architecture.
What I find amusing sometimes is how dogmatic the community can be sometimes when approaching problems (or finding solutions). Our industry developed these practices and patterns through many trials, however, it's always important to ask whether it's suited to the problem at hand.
In my opinion, the best thing about the TDD is Dead video referenced in this video was to hear conflicting opinions and having an open mind. I adored hearing how pragmatic Kent Beck was. Also, am a big fan of Jim Coplien as well.
Excellent talk... but the slide at 32:37 has triggered me. I "just about almost" remember "the Fortran days" and when I read on the paper illustrated "Unit testing was a staple of the FORTRAN days" a loud voice is yelling in my head "Was it?!?!" I must admit that I didn't come across the concept of Unit Testing until about 25 years after "the Fortran days".
Very nice talk. I was doing some deep researches about software architecture lately trying to find the one solution. I kinda got to an interesting results anyway. I will definitely share it somewhere once the picture is very clear and when its proven to work well.
the speaker made some important observations here. thanks for sharing.
Simon has a point and a point of view -- which is plausible. But when you listen to him many times, in separate talks, it feels like he has this pattern of inventing problems on how architecture is done (which includes making faces, sarcasm, shrugs etc. !) to get at how good C4 is.
Layered architecture and all those jumbled arch diagrams might have been perfectly useful in some architecture brainstorming session, which we know nothing about. Instead some snapshots of random diagrams are thrown at us in a talk, coupled with how clumsy those are. It is the not-so-fine art of selling !
yes it was mostly bullshit. I saw couple videos today and it is opposite way of how Martin Fowler speaks. Clear and openly explaining his point of view. This guy here speak worst way for technical presentation possible.
Well this was quite interesting, especially the unit testing vs black box testing.
You see, I am a self taught programmer and I came to the black box, component style testing naturally. It seemed stupid to me to unit test as I would need to add complexity to my code base in order to test it which added no benefit. Instead I decided that I would build modules, or self contained components consisting of several objects with a public interface and then test that entire component through the public interface.
Maybe I'm not as bad at coding as I thought I was then...
No, you are great at coding if you follow this practice! All too often I hear the argument that "unit testing" means you have to test "the smallest unit possible". That is a terribly way to write regression tests. The fallacy is that developers then tend to focus on covering the code with tests, instead of covering the _behavior. When you cover the code, you all too often end up with rigid tests that make it harder to evolve your software. What you describe, with componentizing and testing through the public API is critical, because your public API _is the behavior of your component. To me "unit testing" is equatable to the qualities that your tests have, they should be 100% reliable (must always give the same result if the code hasn't changed), fast to run and fail only when a bug is introduced (testing behavior vs implementation is paramount to this).
> Maybe I'm not as bad at coding as I thought I was then...
Whenever I had this thoughts about myself, reality swiftly proved that not only was I as bad as I thought, but even worse than I thought. 😂 But I'm happy for you if you had a better experience.
Java has packages, which can represent components if you structure your code that way.
+1 for a new language where components are first class citizens (or introducing somehow the concept in existing mainstream languages). I agree that it would be a major step toward closing the gap between architecture and code.
If we had the ability to control more precisely who can use a given package, we would not lose TDD in the presented C4 model. Indeed, a test package could be given special privileges. This kind of fine-grain package management can be enforced with tooling around the language.
+Loïc Yvonnet
All modern languages have this now. Script languages have their package manager. GO and Rust have it too. Not sure about Swift (but i assume not)
Thanks for your reply and references.
NB: OCaml has first-class modules.
Very interesting presentation and I tend to agree with all that was said, but why not go one level below the components and show the layers too. Because end of the day the code does need to be layered, may not be for some simple applications, but for most others.
It's up to the developer. But if you want, you can still introduce a class view. But I guess, you may be forced to re-draw this view often ;)
i think 4+1 ,its very flexible and most simple to use ;
Sounds a bit like DDD - where a component is a bounded context.
I actually made a tool to go up and down in architecture. Pinch in and out as the speaker put it. I think it helps to really understand the architecture. The tool does work, but it needs a LOT of improvement to be really useful. It is currently hosted at programwith.us/ but may move in the future. After seeing this talk maybe I’ll get back on that project.
Nice idea!
The container/component diagram concept near 25:00 is great, but it only shows the things. What about the messages? I'll have to try C4 on a small scale this weekend and see how it goes.
Great talk! Practical advice to architects/developers..
Ravioli rather than Lasagne
Great lecture.
What I grasped:
Analyze and adapt.
Until we have all the solutions, we have to think.
Architecture Design must reconciliate structure and code merging them and presenting layers of abstraction in a way that works and actually makes sense.
UML suffers from the same thing as all good ideas. What started with a few diagrams exploded into scores.
This is now reality - an Angular microservice architecture can beautifully mirror Clean Architecture.
Angular is a mess.
I really appreciate the C4 model of Architecture representation where code reflects the abstractions... Only one area which I'm still trying to figure out where Functional Architecture would be defined? Will it part of Context?
15:38 "Still layered architectures: Hexagons, Onions"
Great talk!
Deja Vu all over again. I think a much more important question should be, in 2014 why should anybody not understand architecture and its relation to code? Because this horse gets flogged by every generation. And that is the key point here. What happens to deep craft knowledge when every four years the number of coders doubles. What happens when it takes at least eight years if not longer to get any good at coding, but the number of skilled coders gets diluted by half every four years. You have to flog the same horse every eight to twelve years. And consultants like you take a simple idea and explain and elaborate it to death in the hopes that the lack of knowledge and experience in the current crop of newbies can be overcome by process and structure. It has yet to work in all the decades I've been in this industry, and I would be surprised if it works now. It will only start working when the population of programmers stops doubling and age and experience can distribute itself along a bell curve just like every other mature engineering discipline.
UML too complex? Who thinks that?
Out of interest, what are the classical books on Software Architecture?
The best classic software architecture book I can think of is the "Gang of 4 Patterns" book.
Since most of good modern architecture documentation is in the context of the web, here is a list of relevant architectural topics to Google: N-Tier, MVC, MVVM, Monolithic Vs Microservice, Event Driven Architecture, SQL vs NoSQL, Domain Driven Design, and Clean Architecture. And no software architecture comment would be complete without a nod to object-oriented vs procedural vs functional!
Check this out: th-cam.com/video/HoeiA1zagWU/w-d-xo.html
If tests allow you to refactor easily and is definitely reflect the code, then you have almost all that good architecture should provide you. Yes, it is probably mean that you don't need architecture, or even that you have an architecture of some sort. The only thing missing is pictures, i.e. "common" language for conveying your ideas to the team members and for drawing "a big picture" to choose the direction for refactoring/developing. In a sense your test suite is a big picture of your system, and the main problem that it is a text, a description; and I'm not sure if we've came up with an idea how to generate pictures from books already.
By the way, want to notice, that generating architecture pictures from code, as speaker proposes, is still code first approach, still not waterfall. Your code doesn't change according to architecture/design, but your architecture/design changes according to the way you code.
All life forms from bacteria to humans are software driven systems. They all use the same fundamental software architecture that I call an Intelligent System. For a life form to live, grow, and reproduce it needs intelligence made up of many different intelligent systems. All intelligent systems are knowledge based and the system architecture is based on ten fundamental knowledge contexts. The 10 knowledge contexts are Name, Authors, Purpose, Environment, Language, Configuration, Operation, Owners, Market, and Value. All the code is contained in the Operation context. Everything you do in life results of the actions of intelligent systems knowledge software.
This dude sounds like Simon Cowell
2017: Is TDD dead?
It's 2018
Thanks. 2018: Is TDD dead?
I went to a global meetup for programmers and enthusiasts and I barely could enjoy the meeting since almost the entire meeting was about working with TDD.
I was totally unrelated and even the software downloads rejected my OS.
I hate too many crutches.
To me almost entire talk was a garbage.
WTF?! 9/10 people don't use UML?! What's wrong with these people. UML is like the holy script of coding.
You are the 1/10
Yes.....I am....I do use UML....that's why I wrote that comment lol. Was that a logical deduction or a failed insult? I can't tell haha
I don't use UML either.
jagjit bhatia same here. I use something close to C4 at work. On the other hand it is pathetic anyone would call themselves an architect and not be well versed in UML.