http://www.eden-study.org/articles/2006/abstraction-classes-sw-design_ieesw.pdf
http://stackoverflow.com/questions/704855/software-design-vs-software-architecture?rq=1
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns -- good
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model - 4+1 architectural model
http://www.ibm.com/developerworks/rational/library/feb06/eeles/ --
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
Architectural Patterns vs. Design Patterns
Thursday June 16, 2011
Why am I writing this?
There might be a gray area between the architectural pattern and the design pattern. Some would argue it really depends on the definition of the each concept. But I think most of the time, you should be able to draw a line between those two concepts.
So, does it matter?
yes, I think it’s important to understand the basic differences.
As an example, it’s like you’re comparing apples and oranges if you try to compare the repository pattern to the abstract factory pattern. The reason is simple. The repository pattern is an architectural pattern and the abstract pattern is a design pattern.
I was actually asked this question once by my coworker and It spaced me out a litte because I couldn’t come up with how to answer the question very well. Now I look back, I think what I should have said back then was simply
“That’s not the right question”
Anyhow, that question made me revisit and think about those two concepts and this is how I wish I had responded:
We all read Gang of Four:
I will skip the history of the design patterns in software engineering. We all read Gang of four’s design patterns book or something similar. And we, software engineers should all know what the design pattern is and be proficient at how to apply them.
A pattern is something that repeats:
As the word “pattern” indicates, it’s reusable solutions. In other words, design patterns are somewhat like mathematical formulas such as Pythagorean theorem.
Remember this thing?
File:Pythagorean.svg
a2 + b2 = c2.
Once you understand the pattern and what type of problem you can apply it to, basically that is it. you have already solved the problem.
What about the abstract factory pattern?
The abstract factory pattern was introduced by (or you can say “invented by) Gang of Four and it’s in their book. It’s one of the most useful and widely used patterns. I will skip the details of the pattern.
Button example:
Design patterns are general solutions. I mean they can be applied no matter what problem domains are.
As an example, you can apply the abstract factory pattern when designing GUI models such as a button control. You can write a button factory class that creates a link button, icon button or square button using the same base abstract class such as “BaseButtonControl” or interface such as “IButtonControl”. It makes your program more extensible and flexible when you want to switch to a different type of button or create a new button and replace the existing one. This pattern allows you to minimize impact on your code structure.
Message handler example:
Let’s say you have a platform that processes incoming SMS messages. Over time, you will have to deal with different types of messages such as MMS, Email or twitter feed. You don’t want to create a giant message handler that handles all different types of messages with if or switch statement. Your code becomes spagetti in a minute and it just gets worse as more custom requirements come in for different clients. You might have to embed switch statements with the switch stament. It already gives me an headache only thinking about it. the abstract factory is the perfect solution here to save you from that headache.
Design patterns are reusable solutions:
You can apply a certain design pattern wherever it fits. it’s general solutions just like mathematical formulas. It does not matter whether your problem resides in the presentation layer or data layer.
What about repository pattern?
Has Gang of Four ever mentioned the repository pattern in their book?
the answer is no
because the repository pattern was quite a recent idea and it was introduced by those who came up with the domain driven design concept. I won’t go into much detail of domain driven design here.
Simply put, the repository pattern handles the persistency of your domain models. If you have a domain model representing a person, your IPersonRepository interface is most likely to include the following operations:
Get Person
Save Person
Delete Person
Update Person
Therefore it’s also the repository’s job to handle discrepancies between your domain layer and your infrastructure layer (or you can call it persistency layer).
As an example, the most widely used persistency infrastructure is relational databases such as Oracle, Sql server and MySql in these days. Your domain models don’t always map to the data structures you have in the database. The repository pattern allows you to abstract out all the complicated details and keep the domain layer from getting corrupted by the pressure from the infrastructure layer.
The repository is the facade of the persistency layer
if you really want to find some design pattern that fits in this senario, I would say it’s the facade pattern. But again, don’t get distracted by that idea!
Don’t get confused between the repository pattern and decoupling mechanism
The core idea of the repository pattern is not about decoupling. It’s about dealing with the domain model persistency. Whether you want to decouple your repository using the dependency injection or the service provider technique, it’s your choice and also you can choose not to (although not recommended). Decoupling is a general design software design concept for the flexibility and extensibility of your system while the repository pattern has a specific set of responsibilities in the architecture of your system.
So why the repository pattern is an architectural pattern not design pattern?
The architecture tells you how your system is laid out. Simply put, It’s the highest level breakdowns of your system.
One traditional architectural pattern example is the 3 tier architecture where your system is broken down into presentation, business and data layers.
The domain driven design promotes 4 tier architecture. Presentation, application, domain and infrastructure layers.
And the repository pattern resides in between the domain layer and infrastructure layer. Your domain models should not know anything about the infrastructure and also should be kept pure and independent from it as well. That is why we have the repository to mediate those two layers.
The repository pattern is still a pattern since it’s a reusable solution and handles the problems that repeats. However, the repository pattern becomes only relevant when we talk about this DDD architecture. Its roles and responsibilities are defined in the domain driven design architecture.
It is not mathematical type general solution such as the abstract factory pattern which can be applied anywhere in your system.
Wrap up
Draw a line between architectural patterns and (Gang of 4) design patterns. They are different
Remember the responsibilities of the repository pattern in the realm of the DDD architecture.
Don’t get confused between the repository pattern and general decoupling mechanisms such as DI
MVC, DDD are architectural patterns
Singleton, Adapter, Facade, Factory are design patterns
Tags: design pattern architectural pattern gang of four object oriented programming
http://stackoverflow.com/questions/704855/software-design-vs-software-architecture?rq=1
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns -- good
http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model - 4+1 architectural model
http://www.ibm.com/developerworks/rational/library/feb06/eeles/ --
http://jinwolf.tumblr.com/post/6591954772/architectural-patterns-vs-design-patterns
Architectural Patterns vs. Design Patterns
Thursday June 16, 2011
Why am I writing this?
There might be a gray area between the architectural pattern and the design pattern. Some would argue it really depends on the definition of the each concept. But I think most of the time, you should be able to draw a line between those two concepts.
So, does it matter?
yes, I think it’s important to understand the basic differences.
As an example, it’s like you’re comparing apples and oranges if you try to compare the repository pattern to the abstract factory pattern. The reason is simple. The repository pattern is an architectural pattern and the abstract pattern is a design pattern.
I was actually asked this question once by my coworker and It spaced me out a litte because I couldn’t come up with how to answer the question very well. Now I look back, I think what I should have said back then was simply
“That’s not the right question”
Anyhow, that question made me revisit and think about those two concepts and this is how I wish I had responded:
We all read Gang of Four:
I will skip the history of the design patterns in software engineering. We all read Gang of four’s design patterns book or something similar. And we, software engineers should all know what the design pattern is and be proficient at how to apply them.
A pattern is something that repeats:
As the word “pattern” indicates, it’s reusable solutions. In other words, design patterns are somewhat like mathematical formulas such as Pythagorean theorem.
Remember this thing?
File:Pythagorean.svg
a2 + b2 = c2.
Once you understand the pattern and what type of problem you can apply it to, basically that is it. you have already solved the problem.
What about the abstract factory pattern?
The abstract factory pattern was introduced by (or you can say “invented by) Gang of Four and it’s in their book. It’s one of the most useful and widely used patterns. I will skip the details of the pattern.
Button example:
Design patterns are general solutions. I mean they can be applied no matter what problem domains are.
As an example, you can apply the abstract factory pattern when designing GUI models such as a button control. You can write a button factory class that creates a link button, icon button or square button using the same base abstract class such as “BaseButtonControl” or interface such as “IButtonControl”. It makes your program more extensible and flexible when you want to switch to a different type of button or create a new button and replace the existing one. This pattern allows you to minimize impact on your code structure.
Message handler example:
Let’s say you have a platform that processes incoming SMS messages. Over time, you will have to deal with different types of messages such as MMS, Email or twitter feed. You don’t want to create a giant message handler that handles all different types of messages with if or switch statement. Your code becomes spagetti in a minute and it just gets worse as more custom requirements come in for different clients. You might have to embed switch statements with the switch stament. It already gives me an headache only thinking about it. the abstract factory is the perfect solution here to save you from that headache.
Design patterns are reusable solutions:
You can apply a certain design pattern wherever it fits. it’s general solutions just like mathematical formulas. It does not matter whether your problem resides in the presentation layer or data layer.
What about repository pattern?
Has Gang of Four ever mentioned the repository pattern in their book?
the answer is no
because the repository pattern was quite a recent idea and it was introduced by those who came up with the domain driven design concept. I won’t go into much detail of domain driven design here.
Simply put, the repository pattern handles the persistency of your domain models. If you have a domain model representing a person, your IPersonRepository interface is most likely to include the following operations:
Get Person
Save Person
Delete Person
Update Person
Therefore it’s also the repository’s job to handle discrepancies between your domain layer and your infrastructure layer (or you can call it persistency layer).
As an example, the most widely used persistency infrastructure is relational databases such as Oracle, Sql server and MySql in these days. Your domain models don’t always map to the data structures you have in the database. The repository pattern allows you to abstract out all the complicated details and keep the domain layer from getting corrupted by the pressure from the infrastructure layer.
The repository is the facade of the persistency layer
if you really want to find some design pattern that fits in this senario, I would say it’s the facade pattern. But again, don’t get distracted by that idea!
Don’t get confused between the repository pattern and decoupling mechanism
The core idea of the repository pattern is not about decoupling. It’s about dealing with the domain model persistency. Whether you want to decouple your repository using the dependency injection or the service provider technique, it’s your choice and also you can choose not to (although not recommended). Decoupling is a general design software design concept for the flexibility and extensibility of your system while the repository pattern has a specific set of responsibilities in the architecture of your system.
So why the repository pattern is an architectural pattern not design pattern?
The architecture tells you how your system is laid out. Simply put, It’s the highest level breakdowns of your system.
One traditional architectural pattern example is the 3 tier architecture where your system is broken down into presentation, business and data layers.
The domain driven design promotes 4 tier architecture. Presentation, application, domain and infrastructure layers.
And the repository pattern resides in between the domain layer and infrastructure layer. Your domain models should not know anything about the infrastructure and also should be kept pure and independent from it as well. That is why we have the repository to mediate those two layers.
The repository pattern is still a pattern since it’s a reusable solution and handles the problems that repeats. However, the repository pattern becomes only relevant when we talk about this DDD architecture. Its roles and responsibilities are defined in the domain driven design architecture.
It is not mathematical type general solution such as the abstract factory pattern which can be applied anywhere in your system.
Wrap up
Draw a line between architectural patterns and (Gang of 4) design patterns. They are different
Remember the responsibilities of the repository pattern in the realm of the DDD architecture.
Don’t get confused between the repository pattern and general decoupling mechanisms such as DI
MVC, DDD are architectural patterns
Singleton, Adapter, Facade, Factory are design patterns
Tags: design pattern architectural pattern gang of four object oriented programming
No comments:
Post a Comment