April 2007 - Posts

• Optimizing WPF Application Performance

  If you ever need to figure out why your WPF application is performing so poorly check out this MSDN Article on optimizing WPF Application Performance. Posted Apr 24 2007, 03:50 PM by Joe Ocampo with no comments Filed under: WPF

• A Discussion on Domain Driven Design: Value Objects

  In my previous post we talked about Entities. Entities have a lot of overhead associated with them. They have a full lifecycle from cradle to grave. They also have identity which forces the domain model to be very expressive in tracking and coordinating their transient states. It would be great if we could compositionally break up the Entity into smaller objects that form descriptive attributes of the Entity itself but don’t have identity. Luckily for us these sometimes smaller objects are referred to as Value Objects in Domain Driven Design. NOTE: It is important not to confuse a Value Object with a CLR value type. Value Objects are unaware of the actual programming language. They are high level modeling concepts that lend themselves to elucidating greater incite of the Domain Model. Don’t assume that an int, string or double are Value Objects. Take a look around you I bet you have a container of pens or pencils all with varying tips and colors. You have a pack of gum nearby filled with individual pieces of gum. Looking in your desk you have a container of paper clips of varying size and shape. If you are wearing a pair of sneakers hopefully you have a pair of shoe laces. Let’s consider your wallet, I bet you have currency of some kind in there with varying denominations of value. In the world of DDD we refer to all these objects as Value Objects. Why because we don’t care about the identity of these objects in the context of day to day activities. We don’t care about each individual paperclip when you need to hold papers together, we just care that there are paper clips. When I put on my Nike’s I don’t care about the shoe laces outside of the context of the shoes themselves. If the laces wear out, I simply replace them with new laces not once giving any consideration to the old laces. I don’t look at the old shoe laces, look up their model number and try to find the exact same model number manufactured from the Nike factory. If I had to give you one rule of a Value Object vs. an Entity it would simply be this. "A Value Object cannot live on its own without an Entity." But I think Eric Evans does a better job at describing Value Objects. “An object that represents a descriptive aspect of the domain with no conceptual identity is called a VALUE OBJECT. VALUE OBJECTS are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.” [Evans 2003] I am going to ask you again to hang up your developer or analyst hat and simply read what I am about to write. Try not to apply any pre-dispositional ideas that you have gained through experience. Don’t apply what you do at work. Work with me here! My son’s name is Jay. Jay is 10 years old and goes to school. I really care about Jay, I want to make sure he is safe and I need to know his whereabouts at all times. When I wake up Jay in the morning, he knows that I expect him to brush his teeth, comb his hair and put on his clothes for school. Being a Dad I don’t really care what type of clothes he wears, just as long as they are appropriate for school. So Jay has to make sure he is wearing a tee-shirt, pants and shoes. Let’s stop right here. Let’s model this scenario in a Domain Model. As you can see the Jay Entity mimics the structure that we described above. But let’s talk a little bit about what Jay means to me. Jay has hair and teeth, which is what Jay is to me. His tee shirt, pants and shoes are important to me but they are not Jay. How can we make the model more expressive yet take the attributes of shirt, pants and shoes and still have meaning to me? How about the following model? As you can see I went ahead a created the Attire type. The model is still contains enough information that I have not lost the expressive whole of the Jay Entity having a Tee-Shirt, Pants and Shoes. Since I have taken this path, I have allowed the Jay Entity to have a simpler compositional structure within the domain model. Now if you were paying attention you noticed that I gave Jay an SSN. After all doesn’t he have one? Isn’t this how I could distinguish Jay from other sons or daughters I may have? NO!!! Remember Jay is an Entity and Entities have identity. How do they have identity? They have identity based on the context of the domain model not what the developer or analyst deems necessary to distinguish Jay from the rest of my family. In your family do you call you son, daughter or brother, by saying “Son 000-52-9899 please pick up the trash.” No you simple say “Jay can you please pick up the trash.” So within the domain of my family what makes Jay unique? Within my family how can I guarantee that when I call for him, he will come? I hope you guessed that his name is his identity. Yes it is that simple, his name. Remember YAGNI, well that applies in domain modeling as well don’t complicate the model by coming up with attributes that mean something to the developers but nothing to the customer. So for the sake of time I am going to speed up the modeling here to show you more of my family domain. So here is a more refined model. Talking to myself I discovered that I also have a daughter. So the Jay type didn’t give me near the flexibility that I needed. Now I have and general Kid Entity that I can use for either my son or daughter. I digress, going back to Value Objects. Here is a general question you can ask yourself when you are evaluating your model. "Can the Attire type exist without the Kid type in the given context of the domain?" Meaning from an architectural stand point are you ever going to ask the attire, “Who do you belong to?” Maybe in some other context you could, say for instance a dry cleaning application. Yes I would have to agree that the Attire type, such as a suite, may exist on its own and have its own ID. Then I would have to use the Attire type to figure out what customer it belonged too. But in the family context, No! The Attire cannot exist on its own. It is a Value object of the Kid Entity. In fact in order for me to access the Attire or change anything on the Attire I should have to go through the Kid. This concept of ownership and responsibility is called an Aggregate in DDD. We will talk about that on a later post. As you can see Value Objects are simple in nature but for a reason that still eludes me, are a difficult concept to master in practice. Entities and Value Objects work in tandem to produce a very fluid model. Please don’t get discouraged if you have hard time figuring out what is what. Remember to take a step back and stop thinking like a developer. Talk through the model as if you were the product owner. Usually the Entities and Value Objects pop right out when you do this. Question yourself, “Does this object need identity outside of this object?” “Can I simplify this object by creating a Value Object?” When you answer these questions make sure to put the model in front of the product owner so that they may validate your refactoring. Your model is the code, your code is the model, never forget that. The two must grow organically together and still capture the business domain from the product owner’s perspective. But what if I have an object that isn’t an Entity or a Value object, well this friend is my next post. Services… Posted Apr 23 2007, 12:00 AM by Joe Ocampo with 25 comment(s) Filed under: Domain Driven Design (DDD)

• Technical Support Spoof

  Found this on YouTube and thought I would share it with everyone.  Enjoy. Sorry CS is removing the object tags use the following link http://www.youtube.com/v/YJZccbEZQwg   Posted Apr 22 2007, 05:16 PM by Joe Ocampo with 2 comment(s)

• Tweaking Windows Vista

  I got this from Sam Gentile's blog but I know I am going to forget about it later when I need it, hence the blog post. Tweak Hounds - Tweaking Windows Vista Posted Apr 22 2007, 03:52 PM by Joe Ocampo with no comments

• If the Defence Department can do Agile anyone can!

  The title says it all!  If the defence department can somehow find a way to incorporate agile there isn't any excuse for any industry not to adopt it. Read the case study here. Posted Apr 18 2007, 01:19 PM by Joe Ocampo with no comments

• A Discussion on Domain Driven Design: Entities

  My last post was intended to help better explain how the ubiquitous language forms the back bone of Domain Driven Design (DDD). I am hoping that this post helps to explain some of the more foundational artifacts of DDD, namely Entities. What is an entity? Is it a business object? Is it a class that has persistence? Is it a sentient being manifested in the form of a polymorphic construct that is based on a real world object? Ok well maybe the latter is definitely out of scope but as we see there are many possibilities of what an entity is. Hopefully I will help to shed some light on the subject. Either that or I will help to perpetuate the existing confusion. At least we go somewhere! Let me first start off by what I believe a domain entity is NOT. A domain entity is not a business object! Why do I say this because the term business object has been bastardized to mean all sorts of stupid meanings in the last 10 years! We have presentation tier elements such as a customer form (aren’t forms objects?? Ugggh) being called business objects because they save and update the database from the customer form. We have actual classes that claim to be business objects then get overweighed by the sheer volume of methods and fields on them. Anyone heard of composition? Not to mention they tend to violate Single Responsibility Principle (SRP) all time. These business objects take on the responsibility of knowing how to persist themselves (CSLA) and how to validate themselves even in some cases how to code themselves. Now I am sure there are rare circumstances and I use the term rare with tongue and cheek, that these architectural concepts can be utilized. But the point I am trying to make is that entities are not business objects they are domain entities. My understanding of Domain Driven Design is rooted from Evans book, who I believe has written one of the best books on software analysis and design ever. A bold statement but none the less an accurate one at that. Before I go any further I have to give you some history about why I believe DDD works. It works because I have used it. And I am not talking about a small little shopping cart project. I am talking big enterprise level project with a staff of 10 business analyst, 7 systems analyst and 15 developers! Communication is essential when working with a team this large. DDD came in to save the project countless times especially during our planning and modeling iterations. The concepts while foreign to some bridged the gap between the severally non-technical and the technical camps. Needless to say the project was on time and on budget. If you are a developer take a moment to stop thinking about your code, stop thinking about the database or whatever persistence mechanism you use. If you are an analysts stop thinking about your requirements, or design documents. When you are practicing DDD, a paralleling factor to the ubiquitous language, rest in Model-Driven Development. Model driven development along with the dialog of the ubiquitous language, form the heart of the domain model. Without these two concepts the architecture of the solution to the domain model will be difficult to convey and later maintain. Let’s take a moment and look at the following sentence in more detail. “Model driven development along with the dialog of the ubiquitous language, form the heart of the domain model.” Do you notice the word “dialog”? I can’t stress enough on the importance of this concept of dialog. It is the key word that will help in better understanding entities and other DDD concepts. So let’s get into some dialog. I would like to thank a fellow Los Techie Joshua Lockwood for inspiring me to come up with this scenario. Consider your wallet? How do you know your wallet is yours? Don’t open it up yet. Does it have a certain look to it? Does it have obvious tear or scratch in a certain location? Does it have a distinct odor that only you can smell (if it does that pretty gross dude). The fact of the matter is you know it is your wallet. When I go home at night I usually place my wallet on my nightstand. In the morning when I am about to go out the door I sometimes forget my wallet and ask my son to go and get it. He usually asks me where it is and I always tell him “Where it usually is.” What happens next is magical. Why is this magical, because my wallet is not the only artifact on my nightstand? There are several books, a clock, and a lamp and sometimes my wife puts her purse there. But somehow my son was able to retrieve my wallet because I had showed him early on how to indentify Daddy’s Wallet. "An object defined primarily by its identity is called an ENTITY." [Evans 2003] So what is my wallets identity? Well that depends on the context. Consider the manufacture of the wallet. We can assume that the manufacturer didn’t care about the individual wallet as much as they did the box of wallets that was shipped to the department store. All the manufacture cared about is that box 24A1 contains 24 wallets of style 6789G. The department store took the box and insured it had 24 wallets and added 24 wallets style 6789G to their inventory. The store clerk then took the box to the front of the store and unpackaged each wallet onto a shelf for purchasing. My son, having only 10 dollars to his name purchased a wallet style 6789G from this store to give to me on Father’s day. On Father’s day I opened this magnificent gift and at that point it was my wallet. Taking a cue from the film, Full Metal Jacket; “This is my wallet, there are many like it but this one is mine.” When I ask my son to retrieve my wallet I don’t ask him to retrieve the wallet on my nightstand with the tag on the inside marked style 6789G. I ask him to retrieve my wallet based on the identity I have given it. In my case it is torn in the middle and resembles a worn out paper bag. Think Costanza wallet. The identities in this case are attributes such as color, shape, size, wear. Almost all the developers immediately thought of, “oh easy this is a composite key based on…” You missed the point! The point is listening to what identity means to the customer. Not what it means to a relational database or whatever persistence mechanism you are using. In most real world scenarios of course it will be something as simple as an Order Number but don’t always look for the obvious. Look at what identity means to the customer. Entities mean something to the customer. They care about them. They want to know what happens to them. They want to know when something changes about them. They want to know when Mommy takes the credit card out of them. So let’s take this a little further because like I mentioned above identity isn’t the only characteristic that distinguishes an entity from other objects in the system. They also have life cycles. Just like any other lifecycle, it’s all about birth, change and death after all it is an entity. Going back to my wallet example, lets for a moment consider when I first took it out of its package. It literally came out of a factory in an instantiated state. It didn’t contain anything but it had a lot of potential. It had a pocket for money several smaller pockets for credit cards and a special mini foldout to place my ID. I immediately transferred all the contents of my old wallet over to my new one. Has the state of my wallet changed? Yes, it has, it went from something fresh out of a package to containing new information it didn’t have before. Now I must persist its state. OK here is where my wallet analogy takes a nose dive! Let’s pretend that in order for my wallet to make it to my nightstand it has to go through my wife. I like that. Who better to persist the wallet once it leaves my hand. OK work with me here. She takes the wallet insures that none of credit cards are missing and that her picture is still the first one on the stack. Then she persist the wallet to the nightstand or whatever other container she would like to place it in. At this point I don’t care because when I wake up in the morning I am going to ask the Wife Repository service to retrieve my wallet and I expect it come back the same way I gave it to her. Let’s recap what just happened: Wallet was created at the factory Took it out of the package and I now have a NEW wallet Populated the wallets pockets with my old wallet’s contents (transient) Saved the state of the wallet to the wife repository Praying that when I ask the wife repository for the wallet that it will come back in its original state. An ENTITY is anything that has continuity through a life cycle and distinctions independent of attributes that are important to the application's user. [Evans 2003] I am going to touch on value objects real quick just so you can understand the difference between entities and value objects. Let’s say my wallet contained 1 five dollar bill and 3 one dollar bills, resulting in a total of 8 dollars. Now we all know that all US currency have a unique ID assigned to them. Is that important to me? Do I really care where it was minted or what hands in went through. NO, I just care that it holds its value and it is in my wallet. So when I add money to the wallet it can add money to the pocket container and increment the value. This is the aggregate pattern that we will talk about on a later post. Back to the wallet, since I don’t care about the identity of the money in relation to the wallet, the money is a value object. I will never ask the wife repository for the one dollar bill with the serial number 1A66784GHII7888 to be placed in my wallet. Identity means nothing to me about the money, only its value! In fact let’s say that the wife repository needed a five dollar bill in exchange for 5 one dollar bills. When I ask for the wallet back in the morning it still contains eight dollars but in a slightly different state. (If this were an application I would hope the service would audit the change) I have to find a way to shorten these posts. I never intend for them to be this long but I tend to be rather long winded when I discuss these concepts. My next post with touch a little more on Value Objects. Posted Apr 14 2007, 10:43 PM by Joe Ocampo with 10 comment(s) Filed under: Domain Driven Design (DDD)

• Visual Stuido Meets XBox 360!

  You all have to check this site out!  The videos alone worth it.  Now I can code and game at the same time. Posted Apr 10 2007, 08:01 PM by Joe Ocampo with no comments

• Agile Logistics

  Found this article accidently.  The title caught my eye.  Anyway it is kind of funny how the characteristics that Prof. Fisher outlines mirror that of agile development. An agile supply chain must have two characteristics, Prof. Fisher says. “Clearly, the ability to respond quickly to market conditions would come to most people’s minds,” he says. “The second thing that companies need to be able to do is produce efficiently in small quantities…” Posted Apr 05 2007, 07:24 PM by Joe Ocampo with 1 comment(s) Filed under: Agile Project Management

• RSpec and Behavior Driven Development: Interview with Lead Developers

  InfoQ interviews Dave Astels and Steven Baker, two of the authors of the successful Rspec framework about enabling Behavior-Driven Development in Ruby, and the implications of moving from a test-centric point of view to one that is more specification-driven. The article can be found here. Posted Apr 03 2007, 12:06 PM by Joe Ocampo with no comments Filed under: BDD (Behavior Driven Development)

• A Discussion on Domain Driven Design

  X Driven Development, is what we use to determine if the software we are building works in accordance with what we expect it to do.  But how do we know what we are building is in accordance with the actual business domain?  Do you look to the 500 page requirements document for the answers?  Do you look at the wire frame that looks nothing like what you have actually designed?  Do you trust the acceptance test that the product owner has authored and believes this is the way it should work?  What do you do?  Domain Driven Design complements X Driven Development as well as other agile software development practices by bringing to light the business model that the software is complimenting. By incorporating a model driven approach to software development we enlighten ourselves as well as the product owners and all additional stakeholders on how the system should behave and solve the business need. I believe that we should extend the already proven design methodology of Test Driven Development of “Red, Green, Refactor” by rephrasing it to “Model, Red, Green, Refactor, Refine”. Model: Construct a domain model based on DDD principles. Red: Write failing test or specifications that govern the intended behavior of the model. Green: Write just enough code to make the specification or test pass. Refactor: Refactor the passing code to design patterns that simplify the composition of the code decreasing technical debt. Refine: Refine the model to greater incite based on the code you have written and verify with the product owner. Start Again. Before I go any further let’s look at just what Domain Driven Design is. I am not going to lie to any of you, when I first picked up Eric Evans book 2 years ago. I read it from cover to cover in about a week. When I was done I reflected on what I had read and nothing seemed to stick. I constantly had to read and reread chapters to figure out how Eric’s practices applied to my code. After all I have the TDD and refactoring stuff down how bad could it be? Well fast forward 3 months and I still didn’t quiet grasp many of the concepts. Now I don’t know what happened but one day I had an epiphany reread it again but this time pause after each chapter and reflect on your current architecture but not at the code level but from the business DOMAIN level. Eureka!! Now it all made sense. My code looks nothing like the domain. Don’t get me wrong I had classes that represented entities but the entities themselves weren’t cohesive from the contextual modularization of the domain. Not to mention the Ubiquitous language didn’t exist. Two years later and after rereading DDD for the third time and holding several training seminars I finally got it down. You know they say a picture is worth a thousand words.  So I would like introduce you to the navigational map of the Model Driven Design. Model Driven Design is broken down into the following artifacts: Entities Value Objects Factories Services Aggregates Repositories Each one of these artifacts complements one another and allows us to gain greater insight into the business domain. But before we start talking about these artifacts it is important to note that there is a backbone or glue rather that holds all these artifacts together. It is somewhat of an ethereal force that when applied correctly brings clarity to all that view the model but when not used correctly can wreak havoc and leave a sour taste with everyone involved in domain driven design. Ok that was a little too deep even for me. This glue is referred to as the “Ubiquitous Language”. “A domain model can be the core of a common language for a software project. The model is a set of concepts built up in the heads of people on the project, with terms and relationships that reflect domain insight. These terms and interrelationships provide the semantics of a language that is tailored to the domain while being precise enough for technical development. This is a crucial cord that weaves the model into development activity and binds it with the code.” Evans 2003 The ubiquitous language forms a common thread where the names of classes and specific business operations or constraints are given a common terms that have been brought to fruition by the domain model and agreed upon by ALL stakeholders. For instance in some development groups you are given a requirement. In the requirement it mentions that a potential clients, contact information be stored in the system. Having worked on many CRM systems, you create a class named “Lead”. Other members of the team create another object named “Contact”. Now let’s examine the paradox. You have 3 entities that mean the same thing. Potential Client Lead Contact Now when you have a conversation with the product owner and they mention the term “potential client”, you have two options. Rudely correct him by saying “you mean Lead” of which you will get a blank stare followed by “Well what every YOU call it. Yeah that thing” or you could simply translate in your head Potential Client equals Lead. Either way you have a breakdown in communication. Not to mention if you are using a SQL server as your persistence mechanism the table may be called “Clients”. I know this is an extreme but I don’t know how many times I have seen this in production code. Now let’s take a quick DDD approach. You take the time to meet the product owner and you agree that the you will refer to this entity as “Potential Client”. Nirvana has been achieved why, I will tell you why! Whenever anyone uses the term “Potential Client” in UML, documents, wire frame, CODE!! Everyone knows that this is the “Potential Client”. Ubiquity has been achieved. A moment of silence if you will… Humans in general have a talent for understanding pictures and spoken words more than we do written text. I don’t know if this based on the fact that before written languages, knowledge was passed down from generation to generation based on spoken words (more like grunting) and drawings on wall. Perhaps our brains revert to time tested state of understanding when thought becomes unclear. That explains a majority of my code. But seriously let’s try something quickly to prove my point. Whatever you do, don’t think of a pink elephant! I mean don’t let that thought enter your head. If you are somewhat normal most of you found it impossible to keep such an IMAGE out of your head. The key was the term image. When we recall objects or ideas we tend to symbolize them in our brains with images. When we thought of the elephant we saw an animal with a long nose weighs 2 tons and has big floppy ears. I gave you the value of pink to contrast it even more than you normal train of thought. You didn’t recall the actual word letter for letter “P” “I” “N” “K” “E” “L” “E” “P” “H” “A” “N” “T”. If you did, what time is Judge Wapner coming on? This is only the tip of the iceberg concerning the ubiquitous language and this post is a lot longer than I had intended it to be. More information will be elucidated on ubiquitous language in the next post on “Entities” and that’s when we really start to have some fun. Posted Apr 02 2007, 10:08 PM by Joe Ocampo with 9 comment(s) Filed under: Domain Driven Design (DDD)