6 ms·

Architectures that will inspire your programming

122 points by iamtechaddict 13y ago

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).
kyberias 13y ago
First rule: When you write text and introduce an acronym (e.g. DDD), please define what it means to the readers. This is an article with multiple acronyms but no definitions for them.
- andrzejkrzywda 13y ago
  I'm sorry! It's fixed now, thanks!
  - Trufa 13y ago
    Thanks for the very interesting article. Sorry if its a sill question but I'm a little bit confused. As someone who is barely starting with node.js, I'm curios if this would be a good architecture for a node.js app, or am I getting this wrong? Sorry if the question is not clear, I can clarify if necessary :)
AsymetricCom 13y ago
What really inspires my programming is a RTOS with only the scheduler running in ring-0
nogridbag 13y ago
Thanks for posting this. I'm halfway through Eric Evans book on DDD and have two others in my queue. I find it strange that there's very little discussion about DDD here on HN. Do you have any recommended resources on CQRS?
- andrzejkrzywda 13y ago
  I recommend watching Greg Young's talks on DDD/CQRS http://skillsmatter.com/expert-profile/open-source-dot-net/greg-young http://skillsmatter.com/expert-profile/open-source-dot-net/g...
- cpeterso 13y ago
  Reading Eric Evan's DDD book was an epiphany for me. A less ambitious introduction to DDD is InfoQ's Domain Driven Design Quickly. It's available as a free ebook, too: http://www.infoq.com/minibooks/domain-driven-design-quickly http://www.infoq.com/minibooks/domain-driven-design-quickly
programminggeek 13y ago
I hate to be self-promotional, but if you are interested in Uncle Bob's Clean Architecture, I would love it if you took a look at Obvious Architecture (http://obvious.retromocha.com http://obvious.retromocha.com). It's a working implementation of his ideas in Ruby, but the same structure can easily be done in any OO language. Actually, the implementation would be a lot easier in a language like Go or Scala that has things like type checked interfaces built in.
jrabone 13y ago
Where does JPA fit into Clean Architecture? Seems like annotation-based persistence straddles several boundaries, or else you code your entities multiple times as both "real" entities and DTOs.
- mattgreenrocks 13y ago
  There's still coupling, which may or may not hamper isolated testing. So it is a bit less pure, but perhaps much easier to sell.
mortyseinfeld 13y ago
Any comments on DCI?

122 points by iamtechaddict 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).

kyberias 13y ago

First rule: When you write text and introduce an acronym (e.g. DDD), please define what it means to the readers. This is an article with multiple acronyms but no definitions for them.

andrzejkrzywda 13y ago
I'm sorry! It's fixed now, thanks!
- Trufa 13y ago
  Thanks for the very interesting article. Sorry if its a sill question but I'm a little bit confused. As someone who is barely starting with node.js, I'm curios if this would be a good architecture for a node.js app, or am I getting this wrong? Sorry if the question is not clear, I can clarify if necessary :)

AsymetricCom 13y ago

What really inspires my programming is a RTOS with only the scheduler running in ring-0

nogridbag 13y ago

Thanks for posting this. I'm halfway through Eric Evans book on DDD and have two others in my queue. I find it strange that there's very little discussion about DDD here on HN. Do you have any recommended resources on CQRS?

andrzejkrzywda 13y ago
I recommend watching Greg Young's talks on DDD/CQRS http://skillsmatter.com/expert-profile/open-source-dot-net/greg-young http://skillsmatter.com/expert-profile/open-source-dot-net/g...
cpeterso 13y ago
Reading Eric Evan's DDD book was an epiphany for me. A less ambitious introduction to DDD is InfoQ's Domain Driven Design Quickly. It's available as a free ebook, too: http://www.infoq.com/minibooks/domain-driven-design-quickly http://www.infoq.com/minibooks/domain-driven-design-quickly

programminggeek 13y ago

I hate to be self-promotional, but if you are interested in Uncle Bob's Clean Architecture, I would love it if you took a look at Obvious Architecture (http://obvious.retromocha.com http://obvious.retromocha.com). It's a working implementation of his ideas in Ruby, but the same structure can easily be done in any OO language. Actually, the implementation would be a lot easier in a language like Go or Scala that has things like type checked interfaces built in.

jrabone 13y ago

Where does JPA fit into Clean Architecture? Seems like annotation-based persistence straddles several boundaries, or else you code your entities multiple times as both "real" entities and DTOs.

mattgreenrocks 13y ago
There's still coupling, which may or may not hamper isolated testing. So it is a bit less pure, but perhaps much easier to sell.

mortyseinfeld 13y ago

Any comments on DCI?