Friday, July 21, 2006

Constructing View objects with the Builder pattern

Domain-Driven Design gives us important concepts like Entities, Value objects, Factories, Repositories, Aggregates, Services, but doesn't talk about View objects and how to construct them.

View objects, as I see them, are a kind of DTOs without the burden of DTOs.
While DTOs represent and duplicate domain objects data, View objects simply represent data requested by a view and extracted from one or more domain objects.
What's more important, they cannot be used as replacements of domain objects, because they are immutable containers of simple data.
So, their use is (and must be) restricted to those scenarios where you need read only report-style views and fast performances.

What about View objects construction?

Like discussed in this post from the Domain-Driven Design group, there are different possibilities.
I think the best one is to use the Builder pattern:

Separate the construction of a complex object from its representation so that the same construction process can create different representations.

You can use the Builder pattern for implementing build methods that directly access the data store for constructing different parts of the View object.
This gives you the following advantages:

  • You can separate the process of building your View object in different steps, and use only the steps you need for a particular view page, without even having to construct the full View object.

  • You can have a generic ObjectAViewBuilder with generic buildPartA() and buildPartB() steps, and then having subclasses specify what data you actually need for every given step, i.e. depending on a particular view page.



This gives you better performances and higher flexibility.

Let us go now with a simple example.

Say we have two domain objects: Employee and Office (I'm not going to show interfaces here because they are of no interest in our context).


@Entity()
@Table(name="Employee")
@Proxy(proxyClass=Employee.class)
public class EmployeeImpl implements Employee {

@Id()
private int id;
@Version()
private int version;

@Column(unique=true)
private String matriculationCode;
private String firstname;
private String surname;
@ManyToOne(targetEntity=OfficeImpl.class)
private Office office;

protected EmployeeImpl() {}

public EmployeeImpl(String matriculationCode) {
this.matriculationCode = matriculationCode;
}

public String getFirstname() {
return firstname;
}

public void setFirstname(String firstname) {
this.firstname = firstname;
}

public String getSurname() {
return surname;
}

public void setSurname(String surname) {
this.surname = surname;
}

public String getMatriculationCode() {
return matriculationCode;
}

public Office getOffice() {
return this.office;
}

public void setOffice(Office office) {
this.office = office;
}

public boolean equals(Object obj) {
if (obj == null || !(obj instanceof Employee)) return false;

Employee other = (Employee) obj;

return new EqualsBuilder().append(this.getMatriculationCode(), other.getMatriculationCode()).isEquals();
}

public int hashCode() {
return new HashCodeBuilder().append(this.getMatriculationCode()).toHashCode();
}
}


@Entity()
@Table(name="Office")
@Proxy(proxyClass=Office.class)
public class OfficeImpl implements Office {

@Id()
private int id;
@Version()
private int version;

@Column(unique=true)
private String officeId;
private String name;

protected OfficeImpl() {}

public OfficeImpl(String officeId, String name) {
this.officeId = officeId;
this.name = name;
}

public String getName() {
return name;
}

public String getOfficeId() {
return officeId;
}

public boolean equals(Object obj) {
if (obj == null || !(obj instanceof Office)) return false;

Office other = (Office) obj;

return new EqualsBuilder().append(this.getOfficeId(), other.getOfficeId()).isEquals();
}

public int hashCode() {
return new HashCodeBuilder().append(this.getOfficeId()).toHashCode();
}
}


The two domain entities are annotated with EJB3 annotations, so they are persistent objects.

Now, your application needs some report-style view listing a few employees data, but you don't want to get the full Employee object graph: so you create a marker EmployeeView interface for representing employee related views, and an extended interface for showing just some simple data from an employee and its related office, the SimpleEmployeeView (with related implementation):


public interface EmployeeView extends Serializable {
}


public interface SimpleEmployeeView extends EmployeeView {

public String getMatriculationCode();

public String getFirstname();

public String getSurname();

public String getOfficeName();
}


public class SimpleEmployeeViewImpl implements SimpleEmployeeView {

private String matriculationCode;
private String firstname;
private String surname;
private String officeName;

public String getMatriculationCode() {
return matriculationCode;
}

public void setMatriculationCode(String matriculationCode) {
this.matriculationCode = matriculationCode;
}

public String getFirstname() {
return firstname;
}

public void setFirstname(String firstname) {
this.firstname = firstname;
}

public String getSurname() {
return surname;
}

public void setSurname(String surname) {
this.surname = surname;
}

public String getOfficeName() {
return officeName;
}

public void setOfficeName(String officeName) {
this.officeName = officeName;
}
}


Please note: the view implementation has setters method, while the interface has not. This is because the view (hence its interface) has to be immutable, but setter methods must be used by the builder for constructing the View object.

Once you have some View object, you need a Builder!
So here is the generic Builder interface for constructing generic EmployeeView objects (EmployeeViewBuilder), and its concrete implementation (SimpleEmployeeViewBuilder):


public interface EmployeeViewBuilder {

public void buildEmployee(String matriculationCode);

public void buildEmployeeOffice();

public EmployeeView getEmployeeView();
}


public class SimpleEmployeeViewBuilder implements EmployeeViewBuilder {

private HibernateTemplate hibernateTemplate;
private SimpleEmployeeViewImpl view = new SimpleEmployeeViewImpl();

public void buildEmployee(String matriculationCode) {
List<Object[]> result = hibernateTemplate.find("select e.matriculationCode, e.firstname, e.surname from com.blogspot.sbtourist.domain.EmployeeImpl e where e.matriculationCode = ?", matriculationCode);
for (Object[] values : result) {
view.setMatriculationCode((String) values[0]);
view.setFirstname((String) values[1]);
view.setSurname((String) values[2]);
}
}

public void buildEmployeeOffice() {
if (view.getMatriculationCode() == null) {
throw new IllegalStateException("First call buildEmployee() method!");
}
List<String> result = hibernateTemplate.find("select e.office.name from com.blogspot.sbtourist.domain.EmployeeImpl e where e.matriculationCode = ?", view.getMatriculationCode());
for (String value : result) {
view.setOfficeName(value);
}
}

public SimpleEmployeeView getEmployeeView() {
return this.view;
}

public HibernateTemplate getHibernateTemplate() {
return hibernateTemplate;
}

public void setHibernateTemplate(HibernateTemplate hibernateTemplate) {
this.hibernateTemplate = hibernateTemplate;
}
}



As you can see, SimpleEmployeeViewBuilder builds each part of the View object directly using data access API (in our example, Hibernate API), retrieving only the data it needs.
And, if you have a different employee view page, just implement a different EmployeeView with related EmployeeViewBuilder!

Finally, your Builder objects will have to be used in the Service layer, into view specific methods:


public EmployeeView getEmployeeWithOfficeView(String employeeMatriculationCode) {
EmployeeViewBuilder builder = new SimpleEmployeeViewBuilder();
builder.buildEmployee(employeeMatriculationCode);
builder.buildEmployeeOffice();
return builder.getEmployeeView();
}



I'd like to know your opinion, every feedback is welcome.

Happy building!

Updates
07/25/2006 : Improved example code (thanks to Christofer Jennings).

28 comments:

Pascal Lindelauf said...

Hi Sergio,

Great thing that you’ve given follow-up to the ever interesting discussion on view objects vs. domain objects. I’ve been reading your article with great interest and I definitely see how view objects might be objects that bypass the domain model to get data quickly and in a summarized form. However, even after reading your article, I fail to understand why the Builder pattern is so well suited for constructing view objects in your opinion. The way I understand the GoF’s idea behind the Builder pattern is to have a generic build process, that calls a number of operations on an abstract product (or view, in your case). Each specific type of product implements these operations as relevant for the construction of that particular product. So this pattern focuses on a generic process of constructing specific product types. But how does this particular abstraction help us in constructing view objects? I hope you can elaborate a little bit more on that.

Pascal.

Sergio Bossa said...

Hi Pascal,

thanks to you for your interest!

> I fail to understand why the Builder
> pattern is so well suited for
> constructing
> view objects in your opinion.
> [CUT]
> So this pattern focuses on a generic
> process of constructing specific product
> types. But how does this particular
> abstraction help us in constructing view
> objects?

My point is that I think the construction process of view objects (our product) must have two main features:

1) It has to be generic in the context of a particular type of view, that is, if I have an employee view, I should be able to define different employee views depending on my needs.

2) It must have separated steps, in order to be able to call just a subset of these steps if I need only a subset of the whole data.

These requirements are IMHO provided by the Builder pattern.

As you said in the DDD mailing list, some kind of Facade could do the job (even if with minor flexibility in the build process), but again, I think the Builder to be the best.

What do you think?

Cheers,

Sergio B.

Anonymous said...

A couple of thoughts ...

1. I think the main thing that "Employee Views" have in common is that given an employee view you can find or build an actual employee object. So there is some commonality between the concept of an "Employee Proxy" and and "Employee View".

2. It is possible for a single view to act as a proxy for multiple object types. So you might have a query including both employee and office information which might implement both the an OfficeView and EmployeeView interface.

Bill Hamaker

boz said...

Thanks for the blog Sergio. I like the idea of read-only view objects and builders. And I've got a couple of questions.

1) If view objects are read-only, why do they have public setters in your example? (Am I just nit-picking example code here?)

2) Are the interfaces useful? (related to Bill's comment, I think.)

It seems like view-objects are here to help when we need miscellaneous data from an object (or relational) graph. And it seems the view-object structure is often unique.

For example: The example shows EmployeeView having an "officeName" field. If I want a view with employeeName, employeeEmail, officeName & officeLocation, it seems I'd need to have a view object and builder that doesn't implement EmployeeView or OfficeView. Instead, I guess I'd make a new DataForMyTableView (for lack of a better name). But now the Interfaces are looking like more complexity with little or maybe no gain. So I might just use the builder/view as a pattern to keep things simple.

,chris

Pascal Lindelauf said...

Hi Sergio,

Thanks for your reply. I feel we’re getting closer to the root of the proposed solution. Let’s take it another step further. What I was wondering is: what exactly is the extra value you get when choosing the Builder pattern as opposed to, say, a Façade pattern? As far as I can see (and correct me if I’m wrong), the extra value is that you can define a kind of generic user interface for a particular type of class. For example:

CustomerUI, being generically constructed like so:
1. BuildCustomerHeader()
2. BuildCustomerDetails()
3. BuildCustomerFooter()

Then we could have a CustomerView, that’s being invoked by CustomerUI and which has the following children:
- CompleteCustomerView, which implements all three build operations
- SimpleCustomerView, which only implements the BuildCustomerDetails() operation

The advantage of this approach is the simplification of the user interface. However, that comes at a cost: the creation of the CompleteCustomerView actually takes three separate calls to the database (one for every operation). This might not be a problem in some cases, where the gain of the generic user interface is more important than the loss of query efficiency, but in the problem posted in the DDD forum (which you referred to), I got the feeling that query efficiency took precedence over a generic user interface. And if query efficiency is priority, I still think that a façade with two operations (one for getting the CompleteCustomerView and one for getting the SimpleCustomerView) would be the most appropriate solution.

How do you see this? Does my example match your ideas about how the Builder pattern should work in this case of view objects?

Cheers,

Pascal.

Sergio Bossa said...

Hi Bill,

thanks for your interesting thoughts.

Linking the concept of View object with that of Proxy object is interesting and may deserve another whole post.

Let me know if you have some other thought, or maybe some blog post of yours to point to.

Cheers,

Sergio B.

Sergio Bossa said...

Hi Christofer,

thank you very much for pointing me out the public setters of the SimpleEmployeeView class: I quickly wrote that code as example, and I didn't notice it.
If you re-read the post, I improved the example separating the SimpleEmployeeView interface and implementation, in order to use, outside the builder, only the interface (that has no setter methods).

As you may see (this is related to your second question), having interfaces for view objects helps you in:

1) Honouring the immutability contract: you need to use setter methods in the builder, but you have to exclude them from your contract (that is, your interface), because view clients don't have to change view objects.

2) Gaining flexibility: as already pointed out in my post, if you use interfaces you can define family of related views. This is useful, i.e., if you want to define a base controller (I mean MVC-like controller) configured with a generic EmployeeView to render: doing so, you can use a single controller object for rendering the whole EmployeeView family, because rendering will happen at runtime (maybe via reflection, maybe via some polymorphic method) and you don't have to know the view type in advance.

Hope to have clarified.
What do you think?

Cheers!

Sergio B.

Sergio Bossa said...

Pascal Lindelauf said...

> What I was wondering is: what exactly is
> the extra value you get when choosing
> the
> Builder pattern as opposed to, say, a
> Façade pattern? As far as I can see (and
> correct me if I’m wrong), the extra
> value
> is that you can define a kind of generic
> user interface for a particular type of
> class.

Yes, you've got the main point: having a family of related views and an user interface capable, thanks to builders, of choosing what views and steps to use.

> in the problem posted in the DDD forum
> (which you referred to), I got the
> feeling that query efficiency took
> precedence over a generic user
> interface. And if query efficiency is
> priority, I still think that a façade
> with two operations (one for getting the
> CompleteCustomerView and one for getting
> the SimpleCustomerView) would be the
> most appropriate solution.

Yes, if performances are a VERY HUGE requirement, I agree with you.

Maybe the original author of the post in the DDD mailing list, Jesse, could give us some insight about his problem.

However, very good points, Pascal.

Thanks,

Sergio B.

boz said...

Have you tried making the view-objects' fields final and setting them in a constructor? It looks like the builder work the same, and it could be a (gulp) singleton ... injected of course. :)

And I'm still not convinced polymorphism would be much use once you have fields from two or more object types in one view-object (like in my last message). The UI *could* use polymorphism, but *does* it? I see JavaBean and Map used with dot-notation in the UI. The only polymorphic UI rendering I can think of requires the object to render itself. ... But "what I can think of" is pretty limited.

I wonder what it would look like if ViewObject was generic and implemented Map.

Good stuff, thanks,
Chris

Anonymous said...

Hi Sergio,
Thanks for writing this up. I think there are some very interesting ideas here. But I'm not exactly sure that the builder pattern is the solution to solve my initial problem. I was having an issue with displaying a list of domain object data that requires me to walk the object graph of each of the items in the list. When walking the graph, some associations are lazy loaded which causes a call to the data store. This hit to the database would happen for each object in the list, so I ended up with an n+1 select problem.

View objects sound like a great way to help me solve my problem, but a builder doesn’t seem appropriate for returning a collection of View objects. If I used your solution to return a collection, I would be right back where I started.

I am also wondering about the EmployeeView marker interface. With View objects we are trying to provide data to the UI for display purposes only, but the EmployeeView contains no data properties. The builders go about building objects that implement the marker interface. The EmployeeViewBuilder interface has the method getEmployeeView return the EmployeeView marker interface, yet the implementation of SimpleEmployeeViewBuilder's getEmployeeView method returns a SimpleEmployeeView object. I don't know about Java, but in C# this isn’t possible.

Even if we did know the type that the builder was responsible for constructing, the service layer uses the builders to build the objects but then returns the marker interface. How is the client supposed to know which type of View object they have retrieved without knowing the internals of the service layer and the internals of the builder?

All the implementations I have seen of the builder pattern, have been to construct objects that have the same functionality (They all implement an interface that does something). Since ViewObjects could possibly expose many different data properties, which are what we are really most concerned about with a View object, it doesn’t seem to me that the Builder pattern is the correct solution.

Sergio Bossa said...

Christofer Jennings said...

> Have you tried making the view-objects'
> fields final and setting them in a
> constructor? It looks like the builder
> work the same

If you use the view object constructor and remove all setters, it could be hard to construct the object in different steps!
You'd have to place all retrieved properties of the view object into builder variables, and then construct the view object in the getViewObject() method, using all those stored variables in a very cluttered constructor method .... too much (tedious and inelegant) work to do, I prefer a lot to use interfaces ;)

> I see JavaBean and Map used with
> dot-notation in the UI. The only
> polymorphic UI rendering I can think of
> requires the object to render itself

You said it: dot notation uses reflection, which is able to see the actual class and methods of the view object. So you pass always an EmployeeView, and the UI will always see the appropriate values.
Regarding polymorphism, I think that having an object capable of describing itself is often useful.

> I wonder what it would look like if
> ViewObject was generic and implemented
> Map.

The builder would work (almost) the same: a generic ViewObject could speed up your development, but you'd lose type safety ... it's always a trade-off evaluation matter ;)

Cheers!

Sergio B.

Sergio Bossa said...

Hi Jesse,

thanks for joining this discussion.

> I was having an issue with displaying a
> list of domain object data that requires
> me to walk the object graph of each of
> the items in the list.
> [CUT]
> View objects sound like a great way to
> help me solve my problem, but a builder
> doesn’t seem appropriate for returning a
> collection of View objects.

Jesse, you don't have to return a collection of view objects: you have to return A SINGLE view object containing all the data and collections you care about. Using Hibernate, you can make an HQL projection where you eagerly fetch your collections: this will solve the n+1 selects problem.
Let me know if you need more info, I could write you some concrete example as soon as I find some free time.

> The EmployeeViewBuilder interface has
> the method getEmployeeView return the
> EmployeeView marker interface, yet the
> implementation of
> SimpleEmployeeViewBuilder's
> getEmployeeView method returns a
> SimpleEmployeeView object. I don't know
> about Java, but in C# this isn’t
> possible.

It is called covariance and Java 5 supports it.

> Even if we did know the type that the
> builder was responsible for
> constructing, the service layer uses the
> builders to build the objects but then
> returns the marker interface. How is the
> client supposed to know which type of
> View object they have retrieved without
> knowing the internals of the service
> layer and the internals of the builder?

I disagree: the Application Service layer must provide different methods for different types of views: so, it must return the specific view subtype, and even if C# doesn't support covariance, in your service layer method implementation you can call your builder returning a generic EmployeeView and safely make a cast (because in your service method you have to know what type of view you are constructing).

> All the implementations I have seen of
> the builder pattern, have been to
> construct objects that have the same
> functionality (They all implement an
> interface that does something)

I have to quote the GOF book ... talking about implementation issues of the Builder pattern:

Why no abstract class for products? In the common case, the products produced by the concrete builders
differ so greatly in their representation that there is little to gain from giving different products a
common parent class.


So, I see it is not a problem for the Builder to return different (sub)types of views with different fields.

What do you think?

Cheers!

Sergio B.

Anonymous said...

Hi Sergio, I must be missing something because to me it looks like your example is all about building a single view of an aggragrate and certain associations into a single view. I understand the Hibernate can eagerly fetch collections, but is that really what we are trying to do here? Im talking about returning a collection of objects for displayiing in a list. So the projection itself would be the collection without the need to eagerly fetch another association unless of course you needed that for your view. Something like this:

Employee Name Office
------------- -------
Dave Central
Pete South Region
Susan Central


As far as the service layer, I was just making a commment on your example. You are returning the marker interface that has no data properties when you should be returning the SimpleEmployeeView. So, I agree with you that the service layer should have different methods for returning different types.

Sergio Bossa said...

Jesse Napier said ...

> I understand the Hibernate can eagerly
> fetch collections, but is that really
> what
> we are trying to do here? Im talking
> about
> returning a collection of objects for
> displayiing in a list. So the projection
> itself would be the collection without
> the
> need to eagerly fetch another
> association

Jesse, I'm sorry, maybe I misunderstood your problem. However, I talked about eagerly fetching collections because this is the most well known solution to the n+1 selects problem you cited.

> As far as the service layer, I was just
> making a commment on your example.

Well, it's ok.

So, what type of solution did you choose at the end?

I'm a bit curious ... let us know if you care!

Thanks,
Cheers!

Sergio B.

Roni & Cindy said...

Very interesting discussion indeed!

I think Sergio touched an interesting point on how to build view object and give that responsibility to a specific class.

What I like about this approach against the simple facade one, is that it separates the responsibility to a class, although I doubt the Builder pattern is the right solution (at least in its "GoF style") and would not go as far as to create a hierarchy of view objects and builders. The benefit of a separate class is that it makes it more clear where to create either a single view object to display or to return an entire collection with the needed information.

This post got me thinking about whether we should change our approach on how to thinks about this UI issue”. I have entered my thoughts at my blog.

Sergio Bossa said...

Roni Burd said...

> Very interesting discussion indeed!

Hi Roni,

thanks for your words.
You can read my reply in your blog.

Cheers,

Sergio B.

Anonymous said...

Sergio,

Sorry no blog yet, I should probably create one. Any opinions on the best blog website?

One thing that is confusing about views is the chicken/egg question. Which came first, the view or the domain object?

In your preface you define a view as being an immutable value object extracted from one or more domain objects. However in practice view objects are usually not extracted from domain objects but rather are obtained by bypassing the domain and just reading the database to get the raw data.

In my previous efforts at doing views I usually considered them to be part of the domain - basically a view was the minimal set of information that the user needed to recognize what domain object we are talking about. I tried the idea of hiding primary key details by having the repository use the view object as in PersonRepository.GetPerson(PersonView). Then the client code for a pick list didn't have to worry about pulling the primary key from the view it could just send the whole view to the repository.

I also tried using interfaces with both Person and PersonView implementing IPersonView. By putting IPersonView in the pick lists my application code could be agnostic about whether the UI wanted to store the whole person or just the view object in the pick lists.

Bill Hamaker

Sergio Bossa said...

Bill Hamaker said...

> Sorry no blog yet, I should probably
> create one. Any opinions on the best
> blog website?

Yes, you should create one ;)
I strongly discourage you to use the Blogger service: I use it because I don't want to change the blog address, but it lacks a lot of features.
Maybe you could take a look at the WordPress service.

> One thing that is confusing about views
> is the chicken/egg question. Which came
> first, the view or the domain object?

I think the domain object, because view data is often a subset/aggregated set of domain data.

So I prefer to keep view and domain as different objects.
Then, if I need to merge the two (i.e. for binding values) I use AOP mixins.

Cheers,

Sergio B.

Anonymous said...

Okay, I'll try wordpress.

Here's my very first blog entry about view objects.

http://billhamaker.wordpress.com/

Anonymous said...

Thanks for the blog entry, its an interesting topic that covers an issue that we're dealing with on my project currently.

There are few points I disagree with:

1) I agree with some of the other replies in that I'm not sure that the view objects necessarily come from domain objects, particularly if your creating them for performance.
2) The builder pattern might not be well suited to most cases where these views are needed. For example I use NHibernate and so I'd may a different view class for each situation rather than building partially populated views. I also don't think its a good idea to incrementally build a view, possibly with multiple DB round-trips, considering that one of the aims of these views is to increase performance.
3) I agree that we shouldn't put them on the domain repositories, but I wonder if all we need are special view repositories that return the readonly view objects.

On the builder part you give two reasons for using the pattern:

1) It has to be generic in the context of a particular type of view, that is, if I have an employee view, I should be able to define different employee views depending on my needs.
2) It must have separated steps, in order to be able to call just a subset of these steps if I need only a subset of the whole data.

On point 1 I'd say if you want different employee views use different classes (SRP), mind you if you have an existing Employee view that has 10 fields and your GUI only uses 5 of them then I'd still use it unless performance was suffering.

On a more general theme I wonder if the term view is a good idea.To me it seems a pity to use a term that already has database and GUI meanings.

I also think the "view" idea is not just about performance. Its also about getting the GUI (or presenter) it needs in a simple form. Domain objects are good for modelling the domain but if your displaying a list then a cut-down, customized, flattened view is more suitable. So even if the domain objects were in memory I think there's a bit of a case for having these seperate classes.

Anonymous said...

"but setter methods must be used by the builder for constructing the View object."

Is this a limitation of Java? We make an effort to have most, if not all, objects be immutable. Objects are always built by other objects (factory objects) and they use the contructor to do so. Thus, you would be hard pressed to find a single "set" in any of our 300+ classes.

-Joe

Anonymous said...

I like the idea of view objects and builder pattern. There are some object mapping frameworks that could help us build view objects more easily such as Dozer, DynaDto, ...
By using Dozer or DynaDto, you can save development time a lot. :)

Setya said...

Sergio,

I'm just starting to learn about DDD. So I might be wrong.

Since you can make any kind of query in your builder, doesn't it mean that you risk of creating a leakage in your domain boundary if you're tempted to query objects that come from outside your aggregate root either directly or indirectly (through join) ?

Regards,

Setya

Anonymous said...

Sergio, when I read your code I realise how much a basic programmer I am. Anyhow, onwards and upwards - always something new to learn.

Flerkin McBlerkin said...

I like wrought iron gates, thank for the links!

Hair Transplant Raleigh

Unknown said...

I was lucky enough to get to meet some of Eric Zimmerman’s MFA students and buy wow gold their projects when I guest-taught a class on how indie developers can work with the games press. I recently interviewed Eric and his fellow buy FIFA 13 ultimate team coins local

Unknown said...

Each specific type of product implements these operations as relevant for the construction of that particular product. So this pattern focuses on a generic process of constructing specific product types. But how does this particular abstraction help us in constructing view objects? I hope you can elaborate a little bit more on that.
www.meizu-mx5.com

hou said...

As you said in the DDD mailing list, some kind of Facade could do the job (even if with minor flexibility in the build process), but again, I think the Builder to be the best.
meizu mx5
xiaomi redmi note 2
meizu m2