7 ms·

This article really interests me - mainly because over the last 10 years, I've sort of adopted (independently) a mish-mash of what here is described here as the

by ap22213 13y ago

This article really interests me - mainly because over the last 10 years, I've sort of adopted (independently) a mish-mash of what here is described here as the 'clean architecture', domain-driven design, and the 'ports and adapters' approaches. I have employed these concepts on a dozen or so SaaS products, and the resulting schemes have have worked extremely well, and have been rock-solid frames to work from. However... I think there's a risk in adopting these types of models without having some experienced context in them. Software design has a huge amount of 'art' to it. And, it's so easy to reach the complexity tipping point - where it all come crashing down. For instance, I remember back in the mid-90s when the design patterns book was all the rage. And, shortly thereafter I'd find code just jam-packed with factories and builders and observers and adapters in multiple layers. It was a mess. Similarly, I can see someone reading these and then going out and creating a 'devices' namespace, a 'controllers' namespace, etc. and filling them with all too many classes and interfaces. I can even predict the rise of the 'framework' maven archetype that creates a bunch of extraneous excess. Listen, I've been there and done that, and it just doesn't work well. It just creates a lot of architectural noise. It creates a mess for your development teams. I've learned this the hard way. Trust me. What I recommend is starting very, very slowly. Just like when DI was the rage, and everyone would leap to integrate the most popular DI engine with all its xml configuration files and heavy weight complexity. When, in fact, all you really need at first is a couple of interfaces and a builder class in the entry-point. Don't set out to create an architectural behemoth. That said, I still think a solid 'domain model' should be at the core of it all. If anything, spend a lot of time defining the domain. Work with stakeholders (product managers, subject matter experts, managers, field and support, even developers, etc.) to get it down. Write unit tests that help make the domain very fluent. In my opinion, it's better to have a small core of very well defined domain classes, then trying to boil the ocean. Start small and focus on the quality of the entities. Again, this is just from my trial-by-many-errors experiences.

andrzejkrzywda 13y ago
I fully agree with the risk that certain ideas will be overused. This leads to unnecessary complexity. I also remember the times of the GoF book and the design patterns rage. The ideas behind those architectures require time to think through. The sooner you start, the better. Then, slowly, try adopting them. If you have a side project, then apply it over there. It's crucially important to have a common understanding of the project within a team. The domain knowledge should come from the subject matter experts, but after that it should be a team work to decide which (if any) patterns and architecture should be applied.
- ams6110 13y ago
  Common understanding of the project... yes that is essential. I've got a tangental role on a project right now where that is NOT happening, and predictably the system is a mess. Each developer is being given task assignments by the lead but nobody really understands the overall architecture, goals, and design of the system. I'm actually not sure the lead does either, it's really one of those "make it up as you go" projects. Sadly it'll ultimately be scrapped and have been a waste of time for everyone involved, except to the extent they can learn some lessons from it.
  - andrzejkrzywda 13y ago
    It's essential, but also ... difficult. It's a peopleware problem, more than a technical one. If there's no trust in the whole team, then all the design/architecture challenges are less important. I've just read it today, a good post on this topic: "We all know Conway’s law: “any piece of software reflects the organisational structure that produced it.”. In the same way, communications patterns between people affects the quality of the software. After 6 months working on a greenfield project I realised I could link all the areas with major technical debt to some unsolved personal conflicts in the team." http://bitlyfied.com/2013/12/19/happiness-and-other-technical-requirements-lessons/ http://bitlyfied.com/2013/12/19/happiness-and-other-technica...
ams6110 13y ago
I've sort of adopted (independently) a mish-mash I think when we're not under overbearing management constraints, that's what all good developers do. "No battle plan survives first contact with the enemy" and usually no architecture survives first contact with reality (unless you force it to).
- nikatwork 13y ago
  Meet my "friend", the Architecture Astronaut. They're a developer just like you and suddenly your team leader. They're about to bury your common sense approach six feet deep. :( Although, I still slightly prefer them to my other "friend", the Procedural Bulldozer.
mattgreenrocks 13y ago
Many of these architectures are focusing on keeping the domain model away from frameworks and libraries. And I see considerable pushback on HN and elsewhere towards this idea. I find this trend anti-intellectual (you do want to get better at your craft, don't you?), and contributing to the rapid commoditization of development: settling on "Good Enough" architecture (cough, Rails) so devs can be easily interchangeable. What's alarming is that our languages have gotten far more powerful, but we seem to be reluctant to learn concepts from the past to further propel our understanding of how we solve problems. It seems that improvements in thinking only come when we're force-fed 'progress' by a well-marketed framework with sufficient clout.
- platz 13y ago
  We thought we wanted frameworks to build big complex UI's with things like Dojo and Prototype, and discovered we wanted JQuery instead.
- charlieflowers 13y ago
  I think it's a backlash against complexity, and also some of the backlash is because there is a naiveté that we have outgrown (anytime you outgrow naiveté you look back on your former foolishness with some resentment). Not to say that these architectures are completely bad, by any means. But these 4 architectures can "remind" us of 2 problems: (1) Times when incidental complexity derailed us (whether we ourselves were the misguided ones who pushed it, or whether someone else inflicted it upon us is beside the point), and (2) Times when we thought some architecture or idea was an amazing insight, and then later we found out it was only good due to other limitations in our environment/toolset/mindset. (For example, "design patterns" seemed like the greatest insight ever to the Java programmers at the time, but eventually everyone realized they many of them were just workarounds for Java's limitations. They were elegant in a world of single-inheritance OO, but not that insightful at all for functional programming, or languages with closures, or data-driven imperative programming). So it's a "once bitten, twice shy" feeling. And an anti-hype protection cloak. Note: I'm not saying these architectures are never a good solution. I'm sure there are cases where they are a great fit. But they still remind us of these issues, so they still trigger a bit of a backlash.

by ap22213 13y ago

andrzejkrzywda 13y ago

I fully agree with the risk that certain ideas will be overused. This leads to unnecessary complexity. I also remember the times of the GoF book and the design patterns rage. The ideas behind those architectures require time to think through. The sooner you start, the better. Then, slowly, try adopting them. If you have a side project, then apply it over there. It's crucially important to have a common understanding of the project within a team. The domain knowledge should come from the subject matter experts, but after that it should be a team work to decide which (if any) patterns and architecture should be applied.

ams6110 13y ago
Common understanding of the project... yes that is essential. I've got a tangental role on a project right now where that is NOT happening, and predictably the system is a mess. Each developer is being given task assignments by the lead but nobody really understands the overall architecture, goals, and design of the system. I'm actually not sure the lead does either, it's really one of those "make it up as you go" projects. Sadly it'll ultimately be scrapped and have been a waste of time for everyone involved, except to the extent they can learn some lessons from it.
- andrzejkrzywda 13y ago
  It's essential, but also ... difficult. It's a peopleware problem, more than a technical one. If there's no trust in the whole team, then all the design/architecture challenges are less important. I've just read it today, a good post on this topic: "We all know Conway’s law: “any piece of software reflects the organisational structure that produced it.”. In the same way, communications patterns between people affects the quality of the software. After 6 months working on a greenfield project I realised I could link all the areas with major technical debt to some unsolved personal conflicts in the team." http://bitlyfied.com/2013/12/19/happiness-and-other-technical-requirements-lessons/ http://bitlyfied.com/2013/12/19/happiness-and-other-technica...

ams6110 13y ago

I've sort of adopted (independently) a mish-mash I think when we're not under overbearing management constraints, that's what all good developers do. "No battle plan survives first contact with the enemy" and usually no architecture survives first contact with reality (unless you force it to).

nikatwork 13y ago
Meet my "friend", the Architecture Astronaut. They're a developer just like you and suddenly your team leader. They're about to bury your common sense approach six feet deep. :( Although, I still slightly prefer them to my other "friend", the Procedural Bulldozer.

mattgreenrocks 13y ago

Many of these architectures are focusing on keeping the domain model away from frameworks and libraries. And I see considerable pushback on HN and elsewhere towards this idea. I find this trend anti-intellectual (you do want to get better at your craft, don't you?), and contributing to the rapid commoditization of development: settling on "Good Enough" architecture (cough, Rails) so devs can be easily interchangeable. What's alarming is that our languages have gotten far more powerful, but we seem to be reluctant to learn concepts from the past to further propel our understanding of how we solve problems. It seems that improvements in thinking only come when we're force-fed 'progress' by a well-marketed framework with sufficient clout.

platz 13y ago
We thought we wanted frameworks to build big complex UI's with things like Dojo and Prototype, and discovered we wanted JQuery instead.
charlieflowers 13y ago
I think it's a backlash against complexity, and also some of the backlash is because there is a naiveté that we have outgrown (anytime you outgrow naiveté you look back on your former foolishness with some resentment). Not to say that these architectures are completely bad, by any means. But these 4 architectures can "remind" us of 2 problems: (1) Times when incidental complexity derailed us (whether we ourselves were the misguided ones who pushed it, or whether someone else inflicted it upon us is beside the point), and (2) Times when we thought some architecture or idea was an amazing insight, and then later we found out it was only good due to other limitations in our environment/toolset/mindset. (For example, "design patterns" seemed like the greatest insight ever to the Java programmers at the time, but eventually everyone realized they many of them were just workarounds for Java's limitations. They were elegant in a world of single-inheritance OO, but not that insightful at all for functional programming, or languages with closures, or data-driven imperative programming). So it's a "once bitten, twice shy" feeling. And an anti-hype protection cloak. Note: I'm not saying these architectures are never a good solution. I'm sure there are cases where they are a great fit. But they still remind us of these issues, so they still trigger a bit of a backlash.