On the Interaction of Social Issues and Software Architecture

Most technical fields such as traditional engineering and building architecture have various standard procedures or patterns that can be applied in various scenarios as solutions to recurring problems. In software engineering/architecture however, there are no such standard procedures, the closest we have is in design patterns, and this document represents a variety of those patterns. The twist that is added by this document is one that is often ignored...the culture and structure of the organization. Knowing the social composition of a development team goes a long way to help improve the outcome of a project because it capitalizes on the strengths of the team and also prevents confusion that would otherwise result from unhealthy overlaps. Along with these strategies of divide-and-conquer applied to improve team coordination in development comes the challenge of putting the divided parts back together, and this document does a good job of revealing some of those flags. Most patterns are published listing the flamboyance of applying the patterns; however, very few actually emphasize some of the pitfalls of the patterns--this document does a good job in raising these flags.

DDD: Chapters 10 - 13

These chapters were the most difficult to read in this book. Highly abstract and I did not necessarily understand some of the patterns discussed in the book--eg. conceptual contours. The other patterns such as "intention revealing interfaces", "assertions" and "standalone classes" seemed to resonate material that is generally discussed in most SE books. The "Side-effect-free functions" pattern provides a good route to program safely, if not the developers use, then for those that future developers who try to maintain the software.

DDD: Chapters 7-9

Chapter 7 is another reason of why I love this book; the concepts are well explained and the illustrations are very easy to understand through the use of scenarios and diagrams. The ability to nail down the objects within a software model is a key responsibility for all architects, so being able to establish an approach, such as discussed in this book, adds to my skill set. I love reading this book because it talks about concepts that I already know, but adds a new spin on it allows me to make key decisions when things are not too clear--such us with entity vs. value objects, aggregate boundaries, integrating with legacy systems etc.

Chapter 8 expounds on the idea of refactoring and how it should be done in stages before finally arriving at a breakthrough discovery that can greatly improve the model. Refactoring is essentially like a puzzle; it starts off with little hints that gradually improve the model and then once there is a cleaner picture, provides a smoother and easier transition to the end when a complete picture is attained. I am not saying a real life software domain model will ever become a complete/perfect model (there will always be ways of refining it) but you get the point.

Chapter 9 introduces the specification as a way of introducting contraints as part of the domain model. Specification objects are introduced as possible solutions to validation, selection and generation of objects keeping the contraints in mind. It is interesting how domain-driven design is willing to comprise on decoupling the repository from the domain to improve performance by allowing the use of SQL as substitutes to holding objects in memory for purposes of querying. I don't know if I fancy the approach of trying to link the specification to the repository using double-dispatch, but I guess it is probably the cleanest way of mingling sql with domain objects. I guess this is where frameworks like hibernate make life easy for a developer.

DDD: Chapters 4-6

I find it very interesting how several projects set off with the goal of generating a completely object-oriented model and basing the implementation solely on this model. We have already discussed how challenging it is to keep the code in sync with the conceptual model. Even more difficult, in my experience, is the challenge of keeping business logic out of the UI. Every modern developer knows the rule of keeping java code out of JSPs and yet in the crunch, usually when the PM is breathing down your neck, most developers take the easy way out by settling for "smart UI". Althought, a 100% separation of conceptual layers is probably impossible to attain; I am quite certain that the more separation there is the better. Especially since most frameworks of today provide the separation and allow for object plugins. Also key is the separation of infrastructure from the domain layer, allowing for easy replacement of third part components through the infrastructure layer.

Also discussed in this reading is the expression of the domain model in the form of diagrams, and also certain techniques that are used to improve the representation of objects in the model while keeping in mind the runtime effectiveness of the model. The reading also discusses the differences between entities and value objects, which along with service objects have become a common pattern used to represent models and their communications between layers. I was surprised that no mention of the use of hashCodes in java, especially EJB, was made in the chapter as a means of identifying entities--since most containers use the hashcode to identify entities that are pooled in an EJB container. Last to be discussed is concept of cohesion and coupling within modules, and why the object-oriented paradigm has become the popular choice to model domains.

Chapter 6 reveals very creative ways of representing a domain model, paying particular attention to separation of responsibilities and trying to simplify objects to allow for component replacements, reuse and scalability. Obviously, the concept of a factory in OO design is one that is frequently discussed in patterns such as factory and factory method. This chapter's strategy of creating repositories and trying to mix up the use of factories and repositories is creative and helps simplify the model. Ultimately these patterns discussed in chapter 6 lead us to understand the importance of separation and also how best to merge such concepts into frameworks and allow for plug-in development.

DDD: Chapters 1 - 3

The first 3 chapters of Domain Driven Design (DDD) focuses on the critical ingredients that are necessary in producing a productive software architectural model. It discusses the importance of knowledge crunching, establishing an ubiquitous language and using the application model as basis for further development.

Knowledge crunching is very key in a team-development project that involves technical and non-technical participants. As is often the case, a group of technical developers are given the task of translating business requirements (from stakeholders) into a feasible technical solution, which makes understanding the requirements very key to the success of the project. Eric Evans emphasizes in his book DDD that key to bridging this knowledge gap is knowledge crunching which involves a healthy interaction between the development team and the subject matter experts (SME). During this process, the architect walks through various scenarios with the SME, a process that naturally starts to generate leading questions and helps generate a deeper understanding of subject. This step of interacting with the SME, to help develop a better understanding of the business rules, is a crucial art that an architect must develop. It also helps if the architect is able to use diagrams (eg. UML) to illustrate the various scenarios, but the most important part of this interaction is communication as Evans refers to as establishing a ubiquitous language.

The ubiquitos language discussed is the set of terminologies that is defined by the parties involved, and is well understood by all parties. It comprises of those technical terms that the SMEs have to familiarize themselves with as well as those business terms that the developers have to capture. A word like "code" is used so commonly, and yet could mean many different things to different people; thus, specifically nailing down the meaning of the the word would save several hours of wrong programming.

With an established ubiquitous language, the team can now translate the business requirements to a model and then to an implementation. Evans establishes the importance of tightly coupling the model to the implementation. In short, a hands-on architect is priceless to the consistency of a development cycle--yielding a software product that correlates with the design model.