Domain-Driven Design at ZendCon 2012

Here are the video and the slides from my Domain-Driven Design talk at ZendCon 2012.

If you’re interested in learning more about this topic then I’d recommend reading the original book on the topic of Domain-Driven Design by Eric Evans. Eric also runs a training company called Domain Language which offers training on Domain-Driven Design. I had the privilege of attending his four day hands-on immersion class which I would highly recommend for anyone who wants to take a deep dive into Domain-Driven Design.

Here are some additional resources that may be helpful:

Statement on Burlington Telecom and its Governance

Almost exactly a year ago I was appointed by the City Council of the City of Burlington, Vermont to the Telecommunications Advisory Committee. In this volunteer position, my role has been to advise the City Council on matters related to Burlington Telecom, a municipally owned telecommunications services provider. At the last regular meeting I was elected Chair. Soon after, I learned that the City Council has plans to potentially dissolve this committee at the next City Council meeting this coming Monday, October 15th. We’ve drafted the following statement (also available on the BTAC Documents page) to be read at this meeting which expresses my thoughts on this potential decision.

To the Burlington, Vermont City Council on October 15th, 2012:

This is a statement from the current members of the Burlington Telecom Advisory Committee—often referred to as BTAC. The BTAC is a citizens committee created by the Burlington City Council and its Transportation, Energy, and Utilities Committee. Formed in 2004, the BTAC was designed to “include a measure of citizen input and oversight into the development and deployment of the telecommunications project.”

It is our understanding that the City Council is considering dissolving the BTAC and transferring its responsibilities to the Blue Ribbon Committee. The decision on whether or not to dissolve the BTAC is a decision to be made as part of a political process. We do not see the BTAC as a political entity, but rather as a governance and oversight body. As such, this statement is not intended to influence your decision one way or another. However, we feel that it is important to share our perspective on the future of Burlington Telecom and its governance in the absence of a citizens committee.

The governance and oversight of Burlington Telecom has long been a difficult and complex issue. In 2009, the City Council formed the Blue Ribbon Committee with two primary responsibilities: assess the viability of Burlington Telecom and assess all available options for the financial structure of Burlington Telecom. Due to the nature of the Blue Ribbon Committee’s work, much of its activity has been done in secret executive sessions.

This is not meant as a criticism of the Blue Ribbon Committee. We understand the reasoning behind this approach. The Blue Ribbon Committee feels that public knowledge of some information might put Burlington Telecom at a competitive disadvantage and that it would not be in the public interest for this information to be publicly known. We also understand that the Blue Ribbon Committee feels that conversations with potential Burlington Telecom investors, partners, or purchasers must be kept confidential, at least initially, in order to obtain the best possible terms for the citizens of Burlington. These are arguably good reasons for secrecy around the Blue Ribbon Committee’s work.

In contrast to the Blue Ribbon Committee, the BTAC rarely holds executive sessions and almost all of its activities are open to the public. There are many areas of Burlington Telecom’s governance where transparency better serves the interest of the public. Our concern is that, without the BTAC, transparency into Burlington Telecom’s operations will become almost non-existent. We urge you to consider the importance of transparency and to move forward with options that increase, not decrease, the level of transparency around Burlington Telecom.

The timing of this action is unfortunate. At its last regular meeting, the BTAC elected a new Chair who outlined three main goals for the BTAC moving forward. These goals were: improve communication between the BTAC, the City Council, and the Blue Ribbon Committee; increase public dialogue to channel input to and from the City Council; and define a clear role for the BTAC. We were looking forward to acting on, and have taken initial steps towards, these goals.

We joined the BTAC because we care about Burlington Telecom and the positive impact that we believe it can, and does, have on our city. Burlington Telecom is not just another telecommunications provider. It is critical infrastructure for the 21st century that is owned by us, the citizens of Burlington. This Fall, Burlington Telecom is rolling out 1 Gbps symmetrical broadband speeds. We are one of a handful of cities in the country with access to this type of bandwidth, putting us at a distinct economic advantage.

Market forces alone have failed to create the broadband infrastructure we need. According to Akamai’s Q1 2012 “State of the Internet” report, the United States is ranked 12th in broadband speed, with an average speed of 6.7 Mbps. This Fall, Burlington citizens and business will have access to broadband speeds 150 times as fast as the national average. In comparison, South Korea is ranked highest with an average broadband speed of 15.7 Mbps. Burlington citizens and business will have access to broadband speeds 65 times as fast as the fastest country’s national average.

Burlington Telecom is a critical part of our city’s infrastructure. It belongs to the citizens of Burlington. In order for us to continue to benefit from this infrastructure, it must be governed transparently. Thank you for your time.

Northeast PHP Tickets

Tickets for the Northeast PHP Conference will be going on sale this Thursday, June 28th at a cost of $99 per person. The conference will be taking place on Saturday, August 11th and Sunday, August 12th at Microsoft’s NERD Center in Cambridge, MA and will feature talks from dozens of speakers across four tracks. This event is being organized by Boston PHP (a non-profit organization) and other user groups from the northeast region—it is completely volunteer-driven with the help of some generous sponsors. Tickets will likely sell quickly, so be sure to reserve your seat early!

Sponsor the Boston PHP Northeast Conference

There are several sponsorship opportunities available for the Boston PHP Northeast Conference. Sponsoring this community organized event is a great way for your organization to demonstrate its support for the PHP community. The event will be taking place on on Saturday, August 11th and Sunday, August 12th at Microsoft’s NERD Center in Cambridge, MA and will be focused around four tracks:

  • Core PHP
  • Web Development
  • Training
  • User Experience (UX)

We are primarily looking for in-kind sponsorships. Some items available to sponsor include (items are subject to change—this is not a final list):

  • Gold:
    • Speaker Dinner
    • T-Shirts for Attendees
    • Evening Event on Saturday
  • Silver:
    • A Speaker’s Travel Expenses (see below for more details)
    • Breakfast on Saturday or Sunday
    • Lunch on Saturday or Sunday
  • Bronze:
    • Coffee on Saturday or Sunday
    • Afternoon Snacks on Saturday or Sunday
    • Raffle Items (e.g. books, magazines, training, software)

We’re also looking for media sponsors, if you’d like to help promote the event. All of the sponsorship levels (Gold, Silver, Bronze, and Media) include a sponsorship listing on the event website and the ability to send us promotional swag to give to attendees. The Gold, Silver, and Media sponsorship levels include some visual presence at the event. Gold sponsors will get more prominent visual presence and a mention during the opening and closing keynotes.

One great way that you can sponsor this event is by helping to pay for a speaker’s travel expenses. A couple speakers who are looking for travel support include Stefan Koopmanschap and Michelangelo van Dam.

Please contact me if you’re interested in sponsoring.

Entity Relationships in a Document Database

This week I attended and presented at CouchConf Boston. I’d like to thank Couchbase for inviting me to speak—it was a great opportunity to meet other CouchDB and Couchbase users. I’ve posted the slides from my Entity Relationships in a Document Database talk to Speaker Deck (and SlideShare, if you prefer):

The presentation covered four patterns for modeling entity relationships in document databases such as CouchDB and Couchbase:

  • Embedded Entities
  • Related Documents
  • List of Keys
  • Relationship Documents

See the presentation for more details. This topic is also covered in the MapReduce Views for SQL Users chapter in the second edition of Writing and Querying MapReduce Views in CouchDB.

Day Against DRM

Day Against DRM vertical bannerToday is the Free Software Foundation’s (FSF) International Day Against Digital Restrictions Management (DRM). This being done as part of the FSF’s Defective by Design anti-DRM campaign. To celebrate Day Against DRM O’Reilly Media is having a sale of 50% off all of its ebooks (which are all DRM-free) including Writing and Querying MapReduce Views in CouchDB and Scaling CouchDB. From O’Reilly Media:

In Celebration of *Day Against DRM*
Save 50% on ALL Ebooks & Videos

Having the ability to download files at your convenience, store them on all your devices, or share them with a friend or colleague as you would a print book, is liberating, and is how it should be. If you haven’t tried a DRM-free ebook or video, we encourage you to do so now. And if you’re already a fan, take advantage of our sale and add to your library.

For one day only, you can save 50% on all O’Reilly, No Starch, and Rocky Nook ebooks and videos. Use code: DRMFREE

Ebooks from oreilly.com are DRM-free. You get free lifetime access, multiple file formats, free updates. Deal expires May 4, 2012 at 11:59pm PT and cannot be combined with other offers.

Speaking at CouchConf Boston

I will be giving a presentation on Entity Relationships in a Document Database at CouchConf Boston on May 15th. The talk description:

Unlike relational databases, document databases like CouchDB and Couchbase do not directly support entity relationships. This talk will explore patterns of modeling one-to-many and many-to-many entity relationships in a document database. These patterns include using an embedded JSON array, relating documents using identifiers, using a list of keys, and using relationship documents.

Additionally, this talk will address how each entity relationship pattern equates to its equivalent in a relational database. I’ll be discussing the relevant differences between document databases and relational databases such as:

  • Document databases do not have tables
  • Each document can have its own schema
  • There is no built-in concept of relationships between documents
  • Views/indexes are queried directly instead of being used to optimize more generalized queries
  • A column within a result set can contain a mix of logical data types
  • There is typically no support for transactions across document boundaries

This talk is based on the MapReduce Views for SQL Users chapter that I’ve added to the second edition of Writing and Querying MapReduce Views in CouchDB.

The MVC Paradox

Use of the Model View Controller (MVC) design pattern is generally accepted as a best practice in modern web applications. Like all design patterns, MVC is a reusable solution to a common problem. The MVC pattern is intended to address the following concerns:

  1. Support for multiple types of clients
  2. Reduce duplicate code when supporting multiple types of clients
  3. Isolating domain logic from the user interface

Note that items 2 and 3 are both dependent on item 1. Support for multiple types of clients is the single driving force behind the MVC design pattern. Following are some examples of client types:

  • Web Browsers
  • API Clients
  • Admin Processes (e.g. CLI, cron, daemon)
  • Unit Tests
  • Native GUI

Realistically, how many of these different client types do you need to support? If you’re taking a RESTful approach, then Web Browsers and API Clients can be combined into one type of client, which we can just call User Agents. Likely you’re not building a Native GUI. This leaves you with the following three types of clients to support:

  • User Agents
  • Admin Processes
  • Unit Tests

Do you really need to use the MVC design pattern in order to support User Agents, Admin Processes, and Unit Tests? Likely not. That’s not to say that there aren’t benefits to isolating domain logic from the user interface. However, if you don’t need to support multiple types of clients you should really question your use of the MVC design pattern. There are many approaches one can take to separating the domain logic and the user interface, of which MVC is just one.

This bring me to The MVC Paradox. Modern MVC web frameworks inadvertently encourage the coupling of domain logic and user interface. If you don’t need to support multiple types of clients, then decoupling the domain logic from the user interface is the only reason left to use the MVC design pattern.

Modern MVC web frameworks often involve a lot of boilerplate code just to support the primary client type of User Agents. This boilerplate code typically does little to help with supporting the other client types of Admin Processes and Unit Tests. As a result of the overhead introduced by this extra boilerplate code, developers often find themselves creating Fat Controllers (a side-effect of The MVC Paradox). Controllers take on too many responsibilities, both vertically and horizontally. Vertically, Controllers start to handle domain logic that should be pushed down to the Model layer. Horizontally, multiple concerns get stuffed into a handful of Controllers. These different horizontal concerns should be separated out into multiple Controllers (the Single Responsibility Principle). The overhead introduced by modern MVC web frameworks leads directly to these problems.

In contrast, take a look at the Slim PHP 5 micro framework. While not a completely RESTful framework, it does a pretty good job of addressing the concerns I’ve laid out in this post. Here is the “Hello world” example from Slim’s homepage:

<?php
require 'Slim/Slim.php';
$app = new Slim();
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name!";
});
$app->run();
?>

There is very little boilerplate code involved in handling a User Agent’s request. Minting and handling new routes is incredibly simple. Placing your entire front-end application layer in one file may seem absurd at first. However, it has the nice side-effect of making it painfully obvious if you start to handle domain logic outside of your Model layer or if one route is doing too many things. If your front-end application is large enough, then you can organize your routes into separate files.

This post is not intended to discourage you from using an MVC web framework. There are certainly times when such a framework is useful. As with any technology decision, carefully consider what problem you’re trying to solve and what technology will best address your problem set. Sometimes your technology choice can undermine the very purpose of using that technology in the first place, as is the case with The MVC Paradox.

Update (12/10/2012): This blog post has been translated into Serbo-Croatian by Jovana Milutinovich of Webhostinggeeks.com.

Boston PHP Northeast Conference Call for Papers Closing!

The Boston PHP Northeast Conference’s Call for Papers will be closing on Thursday, April 12th so be sure to get your talk submissions in before then! The conference will be taking place on Saturday, August 11th and Sunday, August 12th at Microsoft’s NERD Center in Cambridge, MA and will be focused around four tracks:

  • Core PHP
  • Web Development
  • Training
  • User Experience (UX)

Boston PHP will be hosting the event in partnership with other northeast regional user groups including the Burlington, Vermont PHP Users Group (which I organize) and the Atlantic Canadian PHP User Group. If you have any questions or are interested in sponsoring then please send a message to Boston PHP.

The Future of CouchDB and Couchbase Server

What’s the future of CouchDB? It’s Couchbase.” —Damien Katz

The future of CouchDB is CouchDB.” —Noah Slater

First of all, don’t panic. The Apache CouchDB project is thriving. There are plenty of core contributors who are dedicated to the project. If you’re using CouchDB, you’re fine. If you’re considering using CouchDB, you’ll be fine. CouchDB has a bright future ahead of it. Couchbase has repeatedly said that they’re not the CouchDB company, so this shouldn’t be a surprise to anyone.

My interpretation of this announcement is that CouchDB is forking. Going forward, you’ll have two choices, either Apache CouchDB or Couchbase Server. The road map for Apache CouchDB will continue to be determined by community consensus. The road map for Couchbase Server will be determined by Couchbase, the company.

CouchDB has two futures: CouchDB and Couchbase Server. Traditionally, forking a project in this manner has been considered a Bad Thing. From The Jargon File entry for forked:

An open-source software project is said to have forked or be forked when the project group fissions into two or more parts pursuing separate lines of development (or, less commonly, when a third party unconnected to the project group begins its own line of development). Forking is considered a Bad Thing — not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking. As a result, major forks (such as the Gnu-Emacs/XEmacs split, the fissionings of the 386BSD group into three daughter projects, and the short-lived GCC/EGCS split) are rare enough that they are remembered individually in hacker folklore.

In my humble opinion, forking should no longer be considered a Bad Thing. Distributed revision control systems, such as Git, have made it much easier to merge changes back-and-forth between forked projects. If an individual or organization wants to take a project in a different direction, great! It sounds like Couchbase Server will be designed to meet a set of needs that are not being met by CouchDB. If so, a fork is perfectly appropriate as now both sets of needs can be met.