Say, we want to include the bounded context in de API naming convention by applying the following pattern:
mybusiness.com/boundedcontext/apiname/v1/toplevelresource
-> where 'apiname' is a combination of bounded context and top level resource
To apply this pattern on the bounded context example for 'meter' by Martin Fowler (https://martinfowler.com/bliki/BoundedContext.html) we might come to the following endpoints:
connection between the grid and a location: mybusiness.com/grid-operations/meter-operations/v1/meters;
connection between the grid and a customer: mybusiness.com/customer-support/meter-support/v1/meters;
the physical meter itself: mybusiness.com/asset-management/meter-management/v1/meters;
How does this look like? Should be RFC 3986 compliant imho. Ideas and suggestions are welcome.
Related
I am currently learning the proxy pattern and have found two different implementations of it in two different books. Please see the links for patterns UML Diagrams as I cannot embed the pictures yet.
Pattern 1
Pattern 2
My teacher says that Pattern 1 is the correct implementation, although most of the tutorials and sources use the Pattern 2 implementation. My teacher argues that Pattern 2 is wrong because "It allows the proxy to call all public methods on the RealSubject, which makes it not really different from the adapter pattern", while Pattern 1 "enforces that the proxy only can call the functions from the interface class inside the real subject"
My questions are:
What are the real differences between these two UML diagrams? Don't they show the same thing in essence?
If Pattern 2 is wrong, why does the majority of sources, including books, use it to show the Proxy pattern?
Thank you for your answers.
The difference between the two diagrams is that in #1 the Proxy references the Subject interface, whereas in #2 the Proxy references the concrete Subject implementation (a.k.a. RealSubject).
Both of these diagrams are correct, because the Gang of Four Proxy pattern covers a number of different use cases: on page 208 they list remote proxy, virtual proxy, protection proxy, and smart reference as different implementations of the same pattern. The implementations vary to the extent that some of them are aware of their concrete subject and some are not.
This distinction between awareness or ignorance of the concrete subject often causes confusion about the differences between the Proxy and Decorator patterns. It should not confuse Proxy with Adapter; because in the Adapter pattern, the Client and Subject have entirely different interfaces (hence the need for an Adapter). Proxy (and Decorator) share a common interface with their Client and Subject.
In general, I know that there are 3 big types of design pattern
Creational Pattern (Factory, Singleton, etc)
Structural Pattern (Composite, Adapter, Proxy, etc)
Behavioral Pattern (Specification, Command, etc)
But I dont know which type I can put the Repository pattern in.
Is Repository pattern in one of three above type? Or is it kind of in the middle of (2) and (3) pattern?
Repository can be viewed as a special kind of Façade (structural) but also as a special kind of Factory (creational). Also, as the Repository often expose collection-like interface, then it might be a special application of Iterator (behavioral).
What I am trying to say is that neither those categories nor patterns themselves are any sort of definite doctrine. There are just some ideas and a language that tries to make them more explicitly visible. These categories are just helpers trying to express somehow what some patterns do. Also patterns are just various expressions of a generic loose coupling principles. Their borders are blurry.
A repository is a specialisation of the Facade pattern which is structural.
I assume you refer to the repository pattern by Martin Fowler.
He says:
Repository: Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
He himself categorizes the pattern as "Object-Relational Metadata Mapping".
If you want to use the categories in the GOF book, I'd put it into the structural pattern category as the focus of this pattern is to present an interface/view to a client, similar to the Adapter/Facade/Proxy patterns.
I've been confused by what I've been reading during my research on the repository pattern. I'm wondering if folks are (incorrectly?) using that word when they simply mean a data access layer.
Since "repository" is not found in the index of Design Patterns (GoF), I've turned to Patterns of Enterprise Application Architecture (Fowler). Fowler seems pretty clear (page 323) when he states that clients create a criteria object and pass it to the repository to get the results. It looks something like this:
public class Person
{
public List<Person> Dependents()
{
Repository repository = Registry.personRepository();
Criteria criteria = new Criteria();
criteria.equal(Person.BENEFACTOR, this);
return repository.matching(criteria);
}
}
Is the criteria object what makes the repository a repository? If not, what does? If abstracting the persistence mechanism (and therefore constructing queries) is the goal, in what way does the repository differ from a simpe DAL/ORM call like this:
public class PersonLogic
{
public List<Person> GetDependents()
{
IPersonData personData = DependencyContainer.Resolve<IPersonData>();
return personData.GetDependents();
}
}
To me, the difference looks like this:
* With the repository pattern, the client constructs different criteria objects and calls the Matching() method on it.
* With the simple DAL, clients just call different methods based on what they want.
Is there more to it than this? Are programmers mistakenly using the term "repository" when they really mean DAL?
EDIT
David Osborne sent this link to Persistence Patterns. It states:
Basically, the Repository pattern just means putting a façade over
your persistence system so that you can shield the rest of your
application code from having to know how persistence works.
That's really what a data access layer is. It really appears to me that a repository and a DAL are the same thing, and maybe a "true" repository uses the criteria object.
Take a look at the "Using the IQueryable interface" section and beyond at Extending and Enhancing the Orders and Registrations Bounded Context. It provides an insightful and balanced discussion of DAO/Repository implementations.
As subsequently highlighted by Bob Horn, the Persistence Patterns articles summarises that:
Basically, the Repository pattern just means putting a façade over your persistence system so that you can shield the rest of your application code from having to know how persistence works.
In general I agree with author's statements, but I'd like to add some details
Difference between Repository and DAL/ORM that first not only abstracts the persistence mechanism, but also provides collection-like interface for accessing domain objects … and isolates domain objects from details of the database access code:
Differences
For external layers, such as Business Logic:
Helps to avoid leaky abstraction. External layers depend on abstraction of Repository, rather than a specific implementation of DAL/ORM. Thus you could avoid all infrastructure and logical dependencies while working with Repository.
operates with domain objects, rather then a instances of POJO/POCO/DTO
CRUD operations applied to collection-like interface provided by Repository, rather then specific DAL/ORM methods. For example .net: working with collection that implements IEnumerable, rather then entity-framework context or nhibernate session
Similarities
Repository contains DAL/ORM underneath and serves same purpose
I'm working on the issue of design patterns. In this case I want to implement design pattern 'Facade'
I know that 'Cocoa Touch' offers us complete solutions for applying design patterns in our projects (for example NSNotificationCenter - implements observer design pattern)
My questions is next: - do we have ability to using design pattern 'Facade' as well as in the case of the observer design pattern.
Now I implement 'Facade' like this:
For example i have some classes which implements some calculations. The 'Facade' class combine all classes which I needed to calculations.
For example i have classes A, B, C and Facade (which contain A, B and C classes).
When I want to calculate something I just create my 'Facade' and pass some argument for calculation. In this case I don't know about classes A, B, C and this Facade object provides me one access point only.
This design pattern encapsulates objects and simplifies the application.
Is it correct implementation?
Another a good example for implementing facade pattern - pizza call service.
For example, pizza service (subsystem) is very large and it consists of three departments (interfaces) : order department, discount department, delivery department. Each departments has own logic and interfaces.
You can simply implement facade pattern on it.
Here this example in more details.
A Facade is defined as unified interface to a bunch of interfaces - sort of higher level interface to reduce the complexity. Instead of dealing with several classes and knowing the API's of each its reduced to the facade. Your explanation looks OK to me.
It is correct explanation (i don't see implementation). Nice association to Facade pattern in real life is remote control - you can run TV functions, DVD and so on.
The motivation behind the facade pattern is to provide a simplified interface for often-used cases, while accommodating the ability to reach past the simplified interface and interact with more complex aspects of the classes behind the facade when neccessary. As you've described your implementation, it would certainly seem to fit the description, and there is no reason you couldn't use a facade pattern in combination with a notification/observer pattern...
Specification pattern is a common pattern used in DDD that encapsulate business logic to respond to one question.
public interface ISpecification<T>
{
bool IsSatisfiedBy(T aSource);
}
public class CustomerHaveDiscountSpec : ISpecification<Customer>
{
bool IsSatisfiedBy(Customer aCustomer)
{
/* ... */
}
}
Which other patterns are common in Domain-Driven Design?
I recommend InfoQ's Domain Driven Design Quickly, which does a good job of distilling the (too) longer book by Eric Evans. Building upon #Pangea's answer, the objects list deserves some description:
Repository: encapsulates persistence and search - typically database
Service: stateless API entity used for aggregate root CRUD
Aggregate Root: an entity whose other child composite entities lack appropriate meaning without it - perhaps the most important aspect from an API perspective when talking about DDD
Value Object: entity whose state does not change after instantiation (e.g. Color), particularly useful in multithreaded programming because using such eliminates concurrency issues
I do not think we call this as patterns but some concepts are repository, aggregate root, value object, entity, domain services, application services. Below two links are helpful
http://dddcommunity.org/resources/ddd_terms
https://dzone.com/refcardz/getting-started-domain-driven