Thiago Pontes

Summary of Domain Driven Design - Refactoring Toward Deeper Insight

2012-10-26T00:00:00-07:00

Refactoring toward deeper insight is a multilevel process, it will be helpful to stop for a moment to see things togetherand try to get a different picture from the domain. Mainly, There are three aspects that you have to look at, first you need to live in the domain, it means that you have to live together with the domain to see the problems closer and often, so you can try different approachs to the same problems, which is what the second aspect say, you should keep looking at things in a different way and third, you will to be free to talk to a domain expert always needed. The classic refactoring scenario involves a developer or two sitting at the keyboard, recognizing that some code can be improved, and then changing it on the fly (with unit tests to verify their results, of course).

You can start your refactoring insights in different ways, it may be a response to a problem in the code or it can be some complexity you found on it, then, rather than apply a standard a change in the code, the developer notes that the main reason to this problem/complexity is related with the domain model, it could be a missing concept, or something wrong with relationships. In a departure from the conventional view of refactoring, this same realization could come when the code looks tidy, if the language of the model seems disconnected from the domain experts, or if new requirements are not fitting. Refactoring might result from learning, as a developer who has gained deeper understanding sees an opportunity for a more lucid or useful model.

Classical descriptions of refactoring sound very steady. Refactoring toward deeper insight usually isn’t. A period of steady refinement of a model can suddenly bring you to an insight that shakes up everything. These breakthroughs don’t happen every day, yet a large proportion of the changes that lead to a deep model and supple design emerge from them. Such a situation often does not look like an opportunity; it seems more like a crisis. Suddenly there is some obvious inadequacy in the model. There is a gaping hole in what it can express, or some critical area where it is opaque. Maybe it makes statements that are just wrong. This means the team has reached a new level of understanding. From their now-elevated viewpoint, the old model looks poor from that viewpoint, they can build a better one.

Summary of Domain Driven Design - Relating Design Patterns to the Model

2012-10-19T00:00:00-07:00

So far, the patterns described in this book are intended specifically for problems related to a domain model in the context of a Model-Driven Design, so how can we know what’s the difference between a common design pattern and a domain pattern? Most design patterns can be used as domain patterns, you just have to give the right emphasis in the context. The motivations of these patterns and the patterns themselves are presented in purely technical terms. But a subset of these elements can be applied in the broader context of domain modeling and design, because they correspond to general concepts that emerge in many domains. Some of them correspond to deep concepts that emerge in domains. It would be nice to draw on this work. To make use of such patterns in domain-driven design, we have to look at the patterns on two levels simultaneously. On one level, they are technical design patterns in the code. On the other level, they are conceptual patterns in the model. So you have to be aware that what matters is the concept that you are trying to represent, and the design patterns can help you with that. When we start to model processes we realize that there is more than one way to describe and do them, so its up to us to decide which way is the best approach to model the problem.

When working on complex domains, you identify an important object that is composed of parts, occasionally even nesting to arbitrary depth. In some domains, each of these levels is conceptually distinct, but in other cases, there is a sense in which the parts are the same kind of thing as the whole, only smaller. When this common behavior is not reflected in the model, you end up having deplicated code/actions at each leval of the hierarchy, thing like this should be avoided. In the end, you should observe the patterns in your domain, and then try to figure out if you need to apply a design pattern to it, and not the inverse.

Summary of Domain Driven Design - Applying Analysis Patterns

2012-10-05T00:00:00-07:00

All terms and patterns described in this books requires a lot of experience, and you will keep getting better through time. After some time you will start to look at domain problems and see a familiar sort of responsability or a familiar web of relationships and you can see how this problem was solved before, what models were needed, and figure out the best approach. This looks like some kind of trial and error patterns where you can keep documenting and shareing this with your team for future use. As Martin Fowler says in his Analysis Patterns: Reusable Object Models:

Analysis patterns are groups of concepts that represent a common construction in business modeling. It may be relevant to only one domain or it may span many domains.

This analysis patterns Fowler presents are the ones that comes with a lot of experience in the field, it comes like a starting point for some problems, at least. They are not technological solutions, they come as guides to help ypu work out a model in a particular domain.

In a mature project, the decisions about the project are often made after some experience about the domain, and this comes after a lot of experimentation. The principle and application of analysis patterns can be explained better by example than through abstract description.

Analysis Patterns are Knowledge to Draw On

These patterns doesn’t give you full solutions, it oftens stimulates your development, and the changes and results comes from insights coming from the analysis. In the middle of this changes there is one kind you should avoid, it’s when you use a term from a well known analysis pattern, you should keep the basic concept intact, however much superficial it might be, and when you introduces this to your language this can take a new whole ubiquitous concept to your domain and this “hide thing” should be avoided.

Summary of Domain Driven Design - Supple Design

2012-09-21T00:00:00-07:00

To have a project accelerate as development proceeds, you need to have a design that is pleasure to work with, a supple design. Supple design is the complement to deep modeling, once you’ve dug out implicit concepts and made them explicit you have the raw material. A supple design reveals a deep underlying model that makes its potential clear. The client developer can flexibly use a minimal set of loosely coupled concepts to express a range of scenarios in the domain. Design elements fit together in a natural way with a result that is predictable, clearly characterized, and robust.

Intention-Revealing Interfaces

If a developer have to dig into the code in order to know how to use an object effectively, the value of encapsulation is lost. It means that the new developer which had to do it will use his interpretation to understand what the code does, this can lead to concept corruption.

To obtain the value of explicitly modeling a concept in the form of a class or method, we must give these program elements names that reflect those concepts. The names of classes and methods are great opportunities for improving communication between developers, and for improving the abstraction of the system.

Side Effect-Free Functions

In computer science, side effect is when the state of something changes, for instance, when you call a function passing an object and you this object’s state, like passing things aroung by reference. This is not a good idea since the developer needs to know exactly what this function does in order to use it, and if the developer has to look at the implementation to use, it’s not a good thing, as we saw in the previous topic. To help with this there are often alternative models and designs that do not call for an existing object to be modified at all. Instead, a new VALUE OBJECT, representing the result of the computation is created and returned. As VALUE OBJECTS are immutable, there are apart from initializers called only during creation, so all their operations are function (in this case, a function is an operation that doesn’t have side effects)

Assertions

Separating complex computations into functions without side effects cuts the problem down to size, but there is still a residue of commands on the objects that produce side effects, and anyone using them must understand their consequences. Assertions make side effects explicit and easier to deal with. Assertions describe state, not procedures, so they are easier to analyze. Class invariants help characterize the meaning of a class, and simplify the client developer’s job by making the objects more predictable. If you trust the guarantee of a post-condition, you don’t have to worry about how a method works. The effects of delegations should already be incorporated into the assertions. This can be done through unit testing and documentation.

Standalone Classes

Interdependencies make models and designs hard to understand. They also make them hard to test and maintain. And interdependencies pile up easily. Every association is a dependency, and understanding a class requires understanding what it is attached to. Those attached things will be attached to still more things, and they have to be understood too. The type of every argument of every method is also a dependency. With one dependency, you have to think about two classes at the same time, and the nature of their relationship. With two dependencies, you have to think about each of the three classes, the nature of the class’s relationship to each of them, and any relationship they might have to each other. If they in turn have dependencies, you have to be wary of those also, and this doesn’t stops! Modules and Aggregates comes to rescue, they are aimed to limit the web of dependencies.

Summary of Domain Driven Design - Making Implicit Concepts Explicit

2012-09-14T00:00:00-07:00

This chapter like the last one is tiny and teach us how important is to make implicit concepts of the domain in explicit fields/relations/etc in the model and design. This transformations of domain models happens when developers recognize a concept that has been hinted or present implicitly in the design, so you can represent it explicitly in the model with one or more objects or relationships. This looks like a breakthrough, but the difference here is that it happens in the early stages of domain design, when the breakthrough happens after a lot of refactoring.

Digging Out Concepts

This concepts can be discovered by listening to the language the team uses while speaking about the domain, which means sometimes you have to search them out. For example, a user have always talked about some item on a report, the item is compose by various objects, but you have never seen the need for an object for that. Then you realize the item on that report is an important domain concept. So, now you and the user understands each other more precisely, and demonstrations of model interaction to solve specific scenarios become more natural. This ends to a cleaner design.

So, basically what you have to do is listen to the language the domain experts use. You can take notes while he speaks and then ask him to clarify some points for you. This is not the old rule for “nouns are objects”, hearing a new word produces a lead, which you follow up with the conversation, with the goal of discovery a useful concept. Or you can use it to avoid ubiquitous language which leads to misunderstand of concepts.

Eventually, the concept you need is not always floating on the surface, or in documents, you may have to dig. The place to dig is the most awkward part of your design, the place where the complicated things happen. You have to actively engage the domain experts in this search, which will validate your new ideas. Other way is to get the requirements from different domain experts or more than once from the same expert, even the same person provides information that is logically inconsistent after careful analysis, such contradictions, which we encounter a lot when digging into software requirements, can be a great clue to deeper models.

Constraints are a particularly important category of model concepts. They often emerge implicitly, so expressing them explicity can improve design. Sometimes it find a natural home in an object or method, even the simple ones should be documented and make it explicity.

Summary of Domain Driven Design - Breakthrough

2012-08-31T00:00:00-07:00

This is a tiny chapter that says when you should do a “breakthrough” your models, which is the way to go after some refactoring. Slowly but surely, the team assimilates knowledge and this knowledge goes to a model. Deep models can emerge gradually through a sequence of small refactorings, so this breakthrough thing isn’t a technique, it’s an event. The challenge here is recognize what is happening and decide how to deal with it.

When you decide that you have to do a breakthrough in a model you have to keep in mind that it is more risk than most of the refactoring, the transition to a really deep model is a profound shift in your thinking and demands a major change to the design.

Summary of Domain Driven Design - The Life Cycle of a Domain Object

2012-08-24T00:00:00-07:00

Every object has a life cycle. An object is born, it likely goes throgh various states, and it eventually dies.

The challenges here:

Maintaining integrity throughout the life cycle
Preventing the model from getting swamped by the complexity of managing the life cycle

This chapter address these issues through three patterns. The first one is Aggregate pattern to avoid a chaotic tangled web of objects, the second is the Factory pattern, to create and reconstitute complex objects, and the last one will be the Repository pattern.

Although repositories and factories do not themselves come from the domain, they have meaningful roles in the domain design. These constructs complete the Model-Driven Design by giving us accessible handles on the model objects.

Aggregates

Minimalist design of associations helps simplify traversal and limit the explosion of relationships somewhat, but most business domains are so interconnected that we still end up tracing long, deep paths through object references.

The problem is acute in a system with concurrent access to the same objects by multiple clients. With many users consulting and updating different objects in the system, we have to prevent simultaneous changes to interdependent objects. Getting the scope wrong has serious consequences. An Aggregate is a cluster of associated objects that we treat as a unit for the purpose of data changes. Each Aggregate has a root and a boundary. The boundary defines what is inside the Aggregate. The root is a single, specific Entity contained in the Aggregate. The root is the only member of the Aggregate that outside objects are allowed to hold references to, although objects within the boundary may hold references to each other. Entities other than the root have local identity, but that identity needs to be distinguishable only within the Aggregate, because no outside object can ever see it out of the context of the root Entity.

Aggregates mark off the scope within which invariants have to be maintained at every stage of the life cycle. The following patterns, Factory and Repository, operate on aggregates, encapsulating the complexity of specific life cycle transitions.

Factories

We should use this pattern when the creation of some object or an entire Aggregate becomes complex, the factories provide encapsulation. Much of the power of objects rests in the intricate configuration of their internals and their associations. An object should be distilled until nothing remains that does not relate to its meaning or support its role in interactions. This mid-life cycle responsibility is plenty. You can have a lot of problems if you overload a complex object with responsibility for its own creation (and this doesn’t make sense).

Complex object creation is a responsibility of the domain layer, yet that task does not belong to the objects that express the model. There are some cases in which an object creation and assembly corresponds to a milestone significant in the domain, such as “open a bank account.” But object creation and assembly usually have no meaning in the domain they are just a necessity of the implementation. So you have to add something to the domain design that is not a Enitity, a Value Object, or a Service. The factory encapsulates de knowledge needed to create a complex object, providing an interface that reflects the goals of the client and an abstract view of the created object.

Repositories

To do anything with an object, you have to hold a reference to it. How do you get that reference? One way is to create the object, as the creation operation will return a reference to the new object. A second way is to traverse an association. You start with an object you already know and ask it for an associated object. Any object-oriented program is going to do a lot of this, and these links give object models much of their expressive power. But you have to get that first object. From a technical point of view, retrieval of a stored object is really a subset of creation, because the data from the database is used to assemble new objects. Indeed, the code that usually has to be written makes it hard to forget this reality. But conceptually, this is the middle of the life cycle of an Entity and the repository enters here. A Customer object does not represent a new customer just because we stored it in a database and retrieved it. To keep this distinction in mind, we refer to the creation of an instance from stored data as reconstitution.

A Repository represents all objects of a certain type as a conceptual set. It acts like a collection, except with more elaborate querying capability. Objects of the appropriate type are added and removed, and the machinery behind the Repository inserts them or deletes them from the database. This definition gathers a cohesive set of responsibilities for providing access to the roots of AGGREGATES from early life cycle through the end.

Summary of Domain Driven Design - A Model Expressed in Software

2012-08-17T00:00:00-07:00

This chapter starts with a discussion about the issues involved to design associations between objects. They are simple to conceive and draw, but implementing them always end up in problems or bad design. This part is focused on making distinctions among the three patterns of model elements that express the model: Entities, Value, Objects and Services.

Associations

The interaction between modeling and implementation is particularly tricky with the associations between objects.

For example, a one-to-many association migth be implemented as a collection in an instance variable. But the design is not necessarily so direct. The design has to specify a particular traversal mechanism whose behavior is consistent with the association in the model. There are at least three ways of making associations more tractable:

Imposing a traversal direction
Adding a qualifier, effectively reducing multiplicity.
Eliminating nonessential associations

For example, a country has had many presidents, so it’s a one-to-many relation, but with can change the direction of this relation from adding just the a Country ->* President, avoiding a “Dilma is president of which country?” use. We can go even futher, as we know a country has only one president at a time, this qualifies a one-to-one relation Country -> President, based on a period. So the question turns to a “Who was the president of Brazil in 2010?”

Entities

Some objects are not defined primarily by their attributes. They represent a thread of identity that runs through time and often across distinct representations. An object must be distinguished from other objects even though they might have the same attributes. Mistaken identity can lead to data corruption. An object that is defined primarily by its identity is called an entity.

Value Objects

Many objects have no conceptual identity. These objects describe some characteristic of a thing. A Value Object is an object that representes a descriptive aspect of the domain with no conceptual identity. They are instantiated to represent elements of the design that we care about only for what they are, not who or which they are.

Value Objects are often passed as parameters in messages between objects. They are frequently transient, created for an operation and then discarded. So, an object can be classified as a Value Object when you care only about the attributes of a model, so it should not have any identity and should be immutable.

Services

“Sometimes, it just isn’t a thing.”

There are important domain operations that can’t find a natural home in an Entity or Value Object. Some of these are activities or action, not things, but since our modeling paradigm is objects, we try to fit them into objects anyway.

A good service has three characteristics

The operation relates to a domain concept that is not a natural part of an Entity or Value Object
The interface is defined in terms of other elements of the domain model.
The operation is stateless

The statelessness here means that any client can use any instance of a particular Service without regard to the instance’s individual history.

This pattern favors interface simplicity over client control and versatility. It provides a medium grain of functionality very useful in packaging components of large or distributed systems. And sometimes a Service is the most natural way to express a domain concept.

Modules

Modules are an old, established design element. There are technical considerations, but congnitive overload is the primary motivation for modularity. Everyone uses Modules, but a few treat them as a full-fledged part of the model. Code gets broken down into all sorts of categories, from aspects of the technical architecture to developers work assignments. Even developers who refactor a lot tend to content themselves with Modules conceived early in the project.

Summary of Domain Driven Design - Isolating the Domain

2012-08-10T00:00:00-07:00

As we know, the domain is where we put the business logic and solve the problems in our software, so it is the most important part, its importance is disproportionate to its size, even in huge projects, the models still isn’t the biggest part our software, so we need to isolate it from the rest of the software, but you can say “Aren’t we doing that by creating models?”, and the answer is yes, but we need to organize it in a way to be able to look at the elements of our model and see them as a system.

Layered Architecture

For an application to support the simple user act of selecting a cargo’s destination form a list of cities, there must be a program that:

Draw a widget on the screen
Queries the database for all the possible cities
Interprets the user’s input and validates it
associates the selected city with the cargo
commits the change to the database

All this code is in just one program, but just a little bit of it is related to the business of shipping. There are all sorts of ways a software might be divided, but the industry has converged in Layered Architectures, and specifically a few fairly standard layers(UI, Application Layer, Domain Layer). A good example of layered architecture is the TCP/IP protocol.

Relating the Layers

Off course the layers can be connected, layers are meant to be loosely coupled, with design dependencies in only one direction, but when an object of a lower level needs to communicate upward (beyond answering a direct query), we need another architectural pattern for relating layers such as callbacks or observers. The Layered architecture is used in most systems today, under various layering schemes, however domain-driven design requires only one particular layer to exist: The domain layer.

The Smart UI “Anti-Pattern”

Many software projects do take and should continue to take a much less sophisticated design approach that is called the Smart UI. But Smart UI is an alternate, mutually exclusive fork in the road, incompatible with the approach of domain-driven design. Which means that nothing applied in this book works with that approach. The principal advantage of this “pattern” is the fact that you can’t migrate to another design approach except by replaceing the entire application.

Summary of Growing OO Software, Guided by Tests - Building on Third-Party Code

2012-07-20T00:00:00-07:00

Our software always ends relying in third party code, through things such as standard APIs, libraries and frameworks, so we must check that we are using this third-party code correctly, with it pushing back at our design, we must find the best balance between elegance and practical use of someone else’s ideias.

Don’t Mock Types You Can’t Change

When we use third party code we usually don’t have the source code, and when we does we don’t have time to completly read it, so we have to rely on the documentation, which is in most cases incomplete or incorrect. Even with the source code, we preferer not to change the code, because is too much trouble too apply private patches every time there’s a new version.

Write an Adapter Layer

If we don’t want to mock an external API, how can we test the code that drives it? We should write a layer of adapter objects, that uses the third-party API to implement these interfaces, we keep this layer as thin as possible, to minimize the amount of potentially brittle and hard-to-test code. There are some exceptions where mocking third-party libraries can be helpful. We might use mocks to simulate behavior that is hard to trigger, such as throwing exceptions.

Mock Application Objects in Integration Tests

As described above, adapter objects are passive, reacting to calls from our code. Sometimes, adapter objects must call back to objects from the application. Event- based libraries, for example, usually expect the client to provide a callback object to be notified when an event happens. In this case we mock the callback interfaces defined in the application, to verify if the adapter is passing the events between the parts as expected.

Summary of Growing OO Software, Guided by Tests - Achieving Object-Oriented Design

2012-07-13T00:00:00-07:00

The design principles discussed in the previous chapter apply to finding the right boundaries for an object so that it work as expected, for instance, a caller wants to know what an object does and what it depends on, but not how it works.

How Writing a Test First Helps the Design

There are three aspects of TDD that help us achieve this design “rules”. First, starting with a test means that we have to describe what we want to achieve before we consider how. This focus helps us maintain the right level of abstraction for the target object. If the intention of the unit test is unclear then we’re probably mixing up concepts and not ready to start coding. It also helps us with information hiding as we have to decide what needs to be visible from outside the object. Seconds, to keep the unit tests understandable we have to limit their scope. Some tests are dozens of lines long, burying the point of the test somewhere in its setup. Such tests tell us that the component they’re testing is too large and needs breaking up into smaller components. And the last one, to construct an object for a unit test, we have to pass its dependencies to it, which means that we have to know what they are. This encourages context independence, since we have to be able to set up the target object’s environment before we can test it.

Value Types

There is a difference between Values and Objects, values are immutable, so they’re simpler and have no meaningful identity; Objects have state, so they have identity and relationships with each other. If we create a Item type that could be represented as a simple String, we can find all the code that is relevant for a change without having to chase through the code, specific types also reduce the risk of confusion, even the simplest ones, as one of the example showed, feet and metres can be represented as numbers but they’re different things.

There are three basic techniques for introducing value types, which we’ve called: breaking out, budding off, and bundling up.

Breaking out

When we find that some code in an object is becoming too complex, its a sign that we should be implementing multiple concerns and that can be break out into other objects or helper types.

Budding off

When we want to mark a new domain concept in the code, we often introduce a placeholder type that wraps a single field, or maybe has no fields at all. As the code grows, we fill in more detail in the new type by adding fields and methods. With each type that we add, we’re raising the level of abstraction of the code.

Bundling up

When we notice that a group of values are always used together, we take that as a suggestion that there’s a missing construct. A first step might be to create a new type with fixed public fields—just giving the group a name highlights the missing concept. Later we can migrate behavior to the new type, which might eventually allow us to hide its fields behind a clean interface, satisfying the “composite simpler than the sum of its parts” rule.

Summary of Growing OO Software, Guided by Tests - Object-Oriented Style

2012-07-06T00:00:00-07:00

So far this book talked a lot about how to get started with the development process and how to keep going using TDD. Now it starts to focus on OO design, an important thing when you start to refactor your code, or even when you start creating mock objects, code that is easy to maintain is more valuable than code easy to write, it means that implementing a feature in the most direct way can damage the maintainability of the system. This chapter focus on how to achieve a good software design even when its become tricky.

Designing for Maintainability

With TDD we grow our systems slice by slice, as the code scales up, the only way we can continue to understand and maintain it is refactoring the code and structuring the functionality into objects, packages and etc. There is two principal heuristics to guide this approach:

Separation of concerns

When we have to change the behavior of a system, we want to change as little code as possible. If all the relevant changes are in one area of code, we don’t have to hunt around the system to get the job done, to achieve this we gather together code that will change for the same reason.

Higher levels of abstraction

The best way for humans to deal with complexity is avoid it by working at higher levels of abstraction, that’s why most people order food from a menu in terms of dishes, rather than detail the recipes used to create them.

Using this you can structure your application towards something like Cockburn’s “ports and adapters” architecture, in which the code for the business domain is isolated from its dependencies on technical infrastructure, such as databases and user interfaces.

No And’s, Or’s, or But’s

Every object should have a single, clearly defined responsibility; this is the “single responsability” principle, when implementing something this principle helps us decide whether to extend an existing object or create a new one. The heuristic here is that we should be able to describe what an object does without using any “and"s or "or"s, if find ourselves using this conjunctions, this object probably needs to be broken up into other objects.

Composite Simpler Than the Sum of Its Parts

All objects in a system are composed of other objects, except for the primitive types built into the language(in some languages even the “primitive” types are objects). When composing objects into a new type, we want the new type to exhibit simpler behavior than all of its component parts considered together. The composite object’s API must hide the existence of its component parts and the interactions between them, and expose a simpler abstraction to its peers, so, the API of a composite object should not be more complicated than any of its components.

Setting up a Ruby on Rails Development Environment on Ubuntu 12.04

2012-07-02T00:00:00-07:00

Yesterday I had to set up a linux machine twice to develop somethings with ruby and rails and in the first time I did it I got some issues with dependencies and stuff, so I decided to make this post to register the steps here :) I hope this become useful for other people too.

First, we need to install some things for ruby and development in general, this includes git, build tools, native libs for the dbs gem, and a nice text editor:

$ sudo apt-get -y install build-essential zlib1g-dev libssl-dev libreadline-dev libyaml-dev libcurl4-openssl-dev curl git-core vim python-software-properties libpq-dev libsqlite3-dev libmysql-ruby libmysqlclient-dev

Then we install rvm to manage our rubies with the latest version of ruby:

$ curl -L https://get.rvm.io | bash -s stable --ruby

RVM has a nice command called requirements that you can run to install any missing dependencies to run it properly:

$ rvm requirements

After all this steps you should have the latest version of ruby and rubygems installed and working, and you can install rails:

$ gem install rails

That’s all, after that you can choose the db you want to use to start your project and install it with apt-get, enjoy your hacking!

Summary of Growing OO Software, Guided by Tests - Maintaining the Test-Driven Cycle

2012-06-29T00:00:00-07:00

This chapter is about how to keep the TDD proccess running, after we start it in our projects. This, and the other chapters are all about how to write tests as we build the system, how we use tests to get early feedback and how we ensure it that the tests continue to support change and to not become an obstacle to the development team.

Separate Tests That Measure Progress from Those That Catch Regressions

The acceptance tests we write to describe a new feature and serves as a feedback, once passing, the acceptance test now represent a completed feature and should not fail again, but if it fails, it means that there is a regression, which means that you broken existing code. We should organize the test suites to reflect different roles, unit and integration tests to support the development team(this tests should run quickly and should always pass), acceptance tests for completed features(to catch regressions and should always pass too, although they might take longer to run) and new acceptance tests represent work to do, and should not pass until the feature is fully implemented.

Start Testing with the Simplest Success Case

We should start by testing the simplest success case. Once working we’ll have a better idea of the real structure of the solution and can prioritize between handling any possible failures we noticed along the way. The tests should be write as clear as possible to be used as an extension for documentation, so this documentation can be used by the development team.

Develop from the Inputs to the Outputs

We start developing a feature by considering the events coming into the system that will trigger the new behavior.The end-to-end tests for the feature will simulate these events arriving. At the boundaries of our system, we will need to write one or more objects to handle these events. It’s tempting to start by unit-testing new domain model objects and then trying to hook them into the rest of the application. It seems easier at the start but we’re more likely to get bitten by integration problems later. We will have wasted time building unnecessary or incorrect functionality, because we weren’t receiving the right kind of feedback when we were working on it.

Unit-Test Behavior, Not Methods

We all know that high test coverage does not guarantee a codebase that is easy to work with. We do better when we focus on the fatures that the object under test should provide, each of which may require collaboration with other objects, we need to know how to use the class to achieve a goal, which means the objects behavior should be right, and not the lines of code, because you could write some code without fully understand the problem and you will end up with a passing test for a wrong idea.

Turning the Cycle

How much unit testing should we do, using mock objects to break external dependencies, and how much integration testing? It depends too much on the context of the team and its environment. The best we can get from the testing part of TDD (which is a lot) is the confidence that we can change the code without breaking it: Fear kills progress. The trick is to make sure that the confidence is justified. So we observe to see how TDD is working for us and adapt it to our testing strategy.

Growing OO Software, Guided by Tests - Kick Starting the Test-Driven Cycle

2012-06-22T00:00:00-07:00

The entire TDD process was described in the other posts, with that we can assume we can grow the system by just slotting the tests for new features into an existing infrastructure, but what about the very first feature, before we have the infrastructure? As an acceptance test, it must run end-to-end to give us the feed back we need about the system’s external interfaces, which means we have to implement a whole automated build and deploy environments for our test cycle and this is a lot of work to do before we can even see the first test fail. Even looking weird you had to automate the build and deploy process from a nonexistent system.

First, Test a Walking Skeleton

It’s hard to write and pass the first acceptance test, because the architecture, the tests and the production code are all moving. One of the symptoms of an unstable development environment is that there is no obvious first place to look when something fails. We can split this into two smaller problems. First, work out how to build, deploy and test a “walking skeleton”, then use that infrastructure to write the acceptance tests for the first meaningful feature. After that, everything will be in place for test-driven development of the rest of the system.

But what is a Walking Skeleton? It’s a is an implementation of the thinnest possible slice of real functionality that we can automatically build, deploy, and test end-to-end, it should include just enough of the automation, the major components and communication mechanisms to allow us to start working on the first feature.

Deciding the Shape of the Walking Skeleton

To build the walking skeleton you will need to make high-level design decisions for you application, we can’t automate the build, deploy, and test cycle without some idea of the overall structure. We don’t need much detail yet, just a broad-brush picture of what major system components will be needed to support the first planned release and how they will communicate. The rule of thumb is that we should be able to draw the design for the walking skeleton in a few minutes on a whiteboard.

Conclusion

Build the walking skeleton can be a lot of work if you’re building a huge application, and it can bring the “chaos” to your application in the first steps of the software development, but as this chart shows, this will save you a lot of problems in the final steps of the development process, so it’s another tradeoff, but I believe that is better to have that chaos moment far away from the deadline date.

Growing OO Software, Guided by Tests - An Introduction to the Tools

2012-06-13T00:00:00-07:00

The book is about techniques to guide the development of OO software using tests, and it’s not about specific technologies, but to demonstrate some techniques in action the book uses some technologies, such as JUnit 4, Hamcrest and jMock2 frameworks.

A Minimal Introduction to JUnit 4

I believe that everybody that got an OO course, has some experience with JUnit framework, in this section we can see some features this framework provide for us, such as expected exceptions and test fixtures.

Expecting Exceptions

The @Test annotation supports an optional parameter expected that declares that this test case expect an exception, with this the test fails if it doesn’t throw an exception or if throws a different exception than the expected one.

Test Fixtures

This is a great feature but under used many times, which provides a fixed state at the start of a test, this ensures that a test is repeatable, so every time a test run it starts with the same state so it can produce the same results. A fixture must be set up before the test runs and torn down after it. The fixture is managed by the class that defines the test. JUnit use the @Before to set the things up, and @After to tear down the fixture.

Hamcrest Matchers and assertThat()

Hamcrest is a framework for writing declarative match criteria, it’s used by others testing frameworks such as JUnit and jMock. A Hamcrest matcher reports whether an object matches or not some criteria. In practice those matchers are used in combination with JUnit’s assertThat(), which uses matchers to say if a assertion fails. The most useful feature of Hamcrest is defining new criteria by combining existing matchers. The not() method is a factory function that creates a matcher that reverses the sense of any matcher passed to it. Matchers are designed so that when they’re combined, both the code and the failure messages are self-explanatory. The Hamcrest is also extensible, you can write your own matcher if you need.

jMock2: Mock Objects

jMock2 plugs into JUnit (and other test frameworks) providing support for mock objects. This framework creates mock objects dinamically, so you don’t have to write your own implementations of the types you want. The core concepts of the jMock are the mockery, mock objects and expectations. A mockery represents the context of the object under test, its neighboring objects, the mock objects stand in for the real neighbors of the object under test while it runs and a expectations decribes how the object under test should invoke its neighbors during the test.

Conclusion

Although the book introduce only tools from the Java world, all this kinds of frameworks can be found in all the common programming language, its good to know the first then when you need something like this in other languages you already know where to look, since most of the implementations are based on this.

Growing OO Software, Guided by Tests - Test-Driven Development with Objects

2012-06-08T00:00:00-07:00

A Web of Objects

The OO design focuses more on the communication between objects than on the objects themselves. An object communicates by messages: It receives messages from other objects and reacts by sending messages to other objects as well, returning a value or exception to the original sender, for instance. A system is built by creating objects and plugging them together so that they can send messages to one another.

When designing a system, it’s important to distinguish between values that model unchanging quantities or measurements, and objects that have an identity, might change state over time, and model computational processes. In the OO languages that we all use, the confusion is that both concepts are implemented through the same language construct, the classes. Values are immutable instances that model fixed quantities. They have no individual identity, so two value instances are effectively the same if they have the same state. This means that it makes no sense to compare the identity of two values; doing so can cause some subtle bugs. Objects, on the other hand, use mutable state to model their behavior over time. Two objects of the same type have separate identities even if they have exactly the same state now, because their states can diverge if they receive different messages in the future.

Follow the Messages

We can enjoy this high-level approach only if the objects used, are well designed, this means that the objects can be aesily pluggable. In practice, this means that they follow common communication patterns and that the dependencies between them are made explicit. A communication pattern is a set of rules that govern how a group of objects talk to each other: the roles they play, what messages they can send and when, and so on. In languages like Java, we identify object roles with (abstract) interfaces, rather than (concrete) classes—although interfaces don’t define everything we need to say.

Unit-Testing the Collaborating Objects

How can we test objects without exposing any of its internal state? One option is to replace the target object’s neighbors in a test with substitutes, or mock objects. We can specify how we expect the tested object will behave to communicate with the others mock objects for a event, this is called “Specifications Expectations”. During the test the mock objects will assert that they have been called as expected. We can use the term mockery for the object that holds the context of a test, creates mock objects, and manages expectations.

Growing OO Software, Guided by Tests - What is the point of TDD?

2012-06-01T00:00:00-07:00

What is the point of Test-Driven Development?

This book starts with a good citation: “One must learn by doing the thing; for though you think you know it, you have no certainly, until you try.”

And this happens a lot with TDD, everybody knows TDD, had heard about it somewhere, knows that use TDD is about to write the tests before everything, knows that this practice has a lot of advantages, but its hard to find someone that actually do TDD, and knows the “fundamentals”, and for many development teams write tests isn’t “real work”. Its the famous phrase: “I already finished it, just need to test”.

Feedback Is the Fundamental Tool

The sooner we can get feedback about any aspect of the project, the better. Many teams in large organizations can release every few weeks, some teams release every few days or even hours, which gives them an order of magnitude increase in opportunities to receive and respond to feedback from real users. With that in mind, a project organized as a set of nested feedback loops, development is incremental and iterative.

Practices That Support Change

We need constant testing to catch regression errors, so we can add new features without breaking the existing ones, through automated tests. Developers spend a lot of time just reading code, so the code must be readable(avoiding obscure one-liners, for example). To achieve this simplicity, we need to constantly refactor our code as we work with it, to improve and simplify its design, to remove duplication, and to ensure that it clearly expresses what it does, in this case the test suites are the feedback to our changes. TDD must be used as a design activity. We should use the tests to clarify our ideas about what we want the code to do.

Test-Driven Development in a Nutshell

The heart of TDD is this cycle: write a test; write some code to get it working; refactor the code to be as simple as possible. Repeat. By refactoring, you must know that, it is about changing the internal structure of an existing body of code without changing its behavior. As we develop the system, we use TDD to give us feedback on the quality of both, its implementation and design. But a project fully covered with unit tests still can be a mess, it could happen when all the unit tests are passing but the code couldn’t be integrated. When implementing a feature, we start by writing an acceptance test, which exercises the functionality we want to build. While it’s failing, an acceptance test demonstrates that the system does not yet implement that feature, when it passes, we’re done. This generates an inner and outer feedback loop in TDD: Write an acceptance test –> write a test –> make the test pass –> (write a acceptance test or refactor), write a test, etc.

Testing End-to-End

An end-to-end test interacts with the system only from the outside, which means, through its interface, by sending messages, by consuming web services and so on. End-to-end means more than just interacting with the system from the outside, it could be used in both, system and the process by which its built and deployed. An automated build, usually triggered by someone checking code into the source repository, will: check out the latest version; compile and unit-test the code; integrate and package the system; perform a production-like deployment into a realistic environment; and, finally, exercise the system through its external access points. This sounds like a lot of effort, but has to be done anyway repeatedly during the software’s lifetime.

Putting the Domain Model to Work

2012-05-24T00:00:00-07:00

Today I started to read this book, it’s about domain driven development, and it has a lot of good advices about development and how to build something useful in the best way possible.

Crunching Knowledge

Software development it’s not about computers or code, it’s always about something else. For instance, when developing software for green peace to map all the area cleared, your software is about ecology, so how can you code for something you don’t understand? You have to learn about the domain, and how to apply this knowledge when creating your models. The first thing I learned was that your models will carry all the bussiness logic from your software(ok everyone knows that), but the new thing here is about the “conception” stage, don’t using the “find the nouns” way of finding your models. Remeber you have to build this without know(yet) about the domain, so you will have to do this with the bussiness expert, usually is your client, which don’t understand about software development, so you have to create your models in a way that your client understands it too, he will use specific words from his area, which you will have to learn, after sometime you and the business expert will start to understand each other. In the end your models will be code this way, and with some guidance, you can even show some code to him for validation. There is were the beauty is. And this “crunching knowledge” as the author says, is one of the most cool things in software development. As a software engineer, you could work with all kind of things, in all areas, because everything needs a software.

Communication and the Use of Language

On a project without a common language, developers have to translate for domain experts, and this translations ends turning into bottle necks, because developers tends to create abstractions that support their design but are not understood by the domain experts, and developers working on different parts of the problem work out their own design concepts and ways of describing the domain. A project faces serious problems when its language is fractured. A solution is to use a “model-based” language, which should be used among developers to describe not only artifacts in the system, but tasks and functionality. This same model should supply the language for the developers and domain experts to communicate with each other, and for the domain experts to communicate among themselves about requirements, development planning and features.

Binding Model and Implementation

As the project growls, the team ends to interprete the models of the diagrams in its own way, the project becomes chaotic and all the efforts made to make good models ends worthless. Most of its lost starts when the code begins, when developers are forced to come up with new abstractions for what was designed by the analists and it happens because wasn’t given adequate access to domain experts for the developers. If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect. At the same time, complex mappings between models and design functions are difficult to understand and, in practice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.

Patterns of Enterprise Application Architecture - Putting It All Together

2012-05-19T00:00:00-07:00

Chapter 8 – Putting It All Together

This post is like a summary of the other posts, here we will sweep everything together and start to answer the tricky question of what patterns to use when designing an enterprise application, the advice here is one that we already gave in the other posts, use this advice to prod your thinking, but don’t use it as a replacement for your thinking. Even if you don’t like the full story of extreme programming, you should still consider this three technical practices: continous integration, test driven development and refactoring.

Starting with the Domain Layer

The start of the process is deciding which domain logic approach to go with. The three main contenders are Transaction Script, Table Module and Domain Model. As said in the post that describe this patterns, to choose between them you have to consider the complexity of your domain logic, something that is hard to quantify and qualify in the beginning of the project, but there is other factors in the decision, in particular, the difficulty of the connection with a database. The simplest of the three patterns(Transaction Script), fits with the procedural model that most people are still comfortable with, which is easy to build on top of a relational database. However as your logic gets more complicated your difficulties multiply exponentially.

Other option is the Domain Model pattern. The biggest difficult is to learning how to use a domain model. This pattern requires skill if it’s to be done well, done poorly it’s a disaster. The second big fault of a Domain Model is its connection to a relational database. But for many, mostly nontechnical, reasons an object database isn’t a possible choice for a enterprise application.

The Table Module represents an attractive middle ground between these poles. It can handle domain logic better than Transaction Scripts and is less complex than Domain Model. It works nicely by playing to the stringths of the relational databse and representing a reasonable factoring of the domain logic.

Down to the Database Layer

Since we decided that the Table Module has the better approach for our enterprise application we have to choose how to connect to our data source. To connect to the database using the Table Module pattern we can choose the Table Data Gateway, where we will hava an object that acts as a gateway to a database table. You usually don’t need any of the other O/R mapping patterns in this context.

The Presentation Layer

In many ways the presentation is relatively independent of the choice of the lower layers. You just have to care if you will provide a rich client interface or a HTML browser interface. A rich client will give you a nicer UI, but will usually take more effort to program, but that’s because they tend to be more sophisticated. If you go the HTML route, you have to decide how to structure your application, the better approach is using the Model View Controller pattern, as the underpinning for your design.

Some Technology-Specific Advice

In this chapter the author also gives some technology specific tips, most for J2EE and .NET. To the java people, the main point is that you don’t need EJBs to build a great enterprise application, you can do it just using POJOs and JDBC, since J2EE provides great design alternatives. In the .NET world, the hype is all about Web services, but he says that there’s no real reason to make the Web server and the domain logic into separate processes in a .NET application, it’s better to use a pattern like Remote Facade.

Patterns of Enterprise Application Architecture - Distribution Strategies

2012-05-11T00:00:00-07:00

Chapter 7 – Distribution Strategies

This chapter is about object distribution, it’s like when you need to run different services in different boxes, this services can be objects, or a set of objects running in different machines, this improves performance because if one box component gets too busy we can add extra boxes for it, using a load balancer. In this chapter we learn why this architecture sucks, and what to do when we need a distribuited architecture.

Remote and Local Interfaces

The primary reason that the distribuition in boxes doesn’t work has to do with a fundamental fact of computers. A procedure call within a process is very fast. A procedure call between two separate processes is orders of magnitude slower. Make that a process running on another machine and you can add another order of magnitude or two, depending on the network. This means that the interface for a remote object should be different from a local one. For instance, in a local object, we create an interface for it to access each class' fields individually, through gets and sets, but in a remote object we will want to set all the field with just one request, and not individually as the local object interface approach, the remote approach focus on minimizing the calls, instead flexibility and extendibility. As we said before that putting each service in a box it’s not good, this is because that you will have another bottle neck when sending messages to the remote objects. A good solution is use clustering, which means run all the services locally and run other instances on multiple nodes.

Working with the Distribution Boundary

As you design your system you try to keep everything locally in a single process, but if you end up needing to distribute something you can isolate this objects and create an interface to use it, this interface will act like a facade for the distributed objects, this is a pattern called Remote Facade. Using a Remote Facade helps minimize the difficulties that the remote interface introduces. This way only the objects that really need a remote service will get the different interface, and this facade can mime a local interface for the other developers. Another known pattern is the Data Transfer Object, it’s used when you not only need to invoke remote methods, but when you need to transfer objects too. This is normally used when you have different processes running, because this pattern acts like the channel between the process to share the object.

Interfaces for Distribution

When this book was written, the interfaces for distributed components have been based on remote procedure calls, but today we see a lot of interfaces based on XML/JSON over HTTP, it’s the famous REST interfaces. This is a handy approach for several reasons, it easily allows a lot of data to be sent, in structured form, in a single roundtrip. Since remote calls need to be minimized, this is a good thing. Another good thing is that all common programming languages has XML/JSON parses so different plataforms can interact between, through it.

Conclusion

Always keep everything together when possible, but when you have to distribute it through multiple processes, you can keep the system clean creating an remote interface for the services that need make/receive remote calls and other interface for the local object to keep everything simple using regular OO. As you saw you can do it easily nowadays using REST.

Patterns of Enterprise Application Architecture - Session State

2012-05-02T00:00:00-07:00

Chapter 6 – Session State

This chapter talks about session states, it’s interesting because I had some problems with this recently in a project I’m developing in the university. I think that if I had read this chapter before it, it could had saved me a couple hours of researching. But, as everything in life, the mistakes served to go deeper in the subject.

The Value of Statelessness

So, what is stateless? An object has behavior and different states, so a true stateless object should be an object without states, it means no fields. But an object like this is awkward, however, this isn’t what most people mean when they talk about statelessness. When people refer to a stateless server they mean an object that doesn’t retain state between requests. An object may have fields, but when you invoke a method on a stateless server the values of the fields are undefined. An example could be a server that returns a web page telling you all about a book, you invoke it by accessing an URL, in the URL you supplu an ISBN number that the server uses to generate the HTTP response based on a database query to retrieve the object from db and show it to the user in a HTML page, once the job is done, these values become useless and don’t influence to the state of the object. But what if you want to keep track of all ISBN viewed by some determined client IP? You gonna need an object that persist between requests, this should be a stateful object. This is a very costly approach, since statelessness fits better in the web(HTTP is a stateless protocol). With a stateless object server you can implement stateful objects, to keep a session state. This session state acts like a transaction and need to be committed to become record data. But we can have consistency problems as describe in the other post about concurrency if the same object has his state changed by two different sources. So, to store session state without losing the correct behavior we can use some patterns to help with it, as we will see below.

Client Session State

This pattern has a simple idea, just store the session state on the client. It’s how the cookies works, there are other several ways to do that, for instance, you can serialize the data into some hidden field on a web form(I always thought this was a ~gambiarra~ lol is there an equivalent to gambiarra in english? but I know there are some cases this could be used, like rails does I guess) or you can hold the data in a object on a rich client, which has been a good approach with JS mainly front-end apps. The problem with the cookies approach is that you are limited with the cookie’s size, other problem is that cookies only works with a single domain, so if your site is separeted into different domain names the cookies won’t travel between them. The main disadvantage of using cookies is when you have to work with a large amount of data, because it has to be transferred in every request. There is also a security issue, all the data transferred through cookies can be sniffed and spoofed/changed.

Server Session State

This approach is to keep the session state on the server’s memory, or in a file on the file system or even in a single table in a database. You can have a kind of map in memory to hold the session ID and the session object can be retrieve from the map to process the request, obviously this consumes a lot of memory. To solve this problem you can serialize the object for a persist store, avoid loosing the object in case that some thing accur with the memory. Other way is creating a table to store the sessions indexed by the session ID, using this approach you will have to worry with the performance if your system have to handle a lot of clients simultaneously. Because it’s simplicity, this pattern has been implemented by default in several application servers.

Database Session State

This is another server-side storage approach, but it involves break the data into tables and fields and storing it like you would store common database entities. The data involved is typically a mix of session data that’s only local to the current interaction and committed data that’s relevant to all interactions. One of the key issues to consider here is the fact that session data is usually considered local to the session and shouldn’t affect other parts of the system until the session as a whole is committed. The advantage here is the gain in performance, you will be using stateless objects on the server, thus enabling pooling and easy clustering. However, you’ll pay with the time needed to pull the data in and out of the database.

Patterns of Enterprise Application Architecture - Concurrency

2012-04-25T00:00:00-07:00

Chapter 5 – Concurrency

This chapter talks about concurrency, one of most tricky parts of software development. It don’t pretend to give a general treatment of concurrency(for that it could need at least a book), but it introduces concurrency issues for enterprise application development. Once its done with the brief introduction about concurrency, we will start to talk about the patterns for handling concurrency. All the problems here discussed can be imagined like the problems that a control version tool deal.

Concurrency Problems

The essential problems of concurrency are the problems that concurrency control systems try to prevent. The bigger problem here is that these system often create a new set of problems in their solutions. The First and simplest problem is called Lost updates. It happens, for instance, when someone is editing one file, then someone else starts to edit the same file and finish it before the first one, so the first one don’t get the changes made by the other, and when he save his version will be write over the other version, updated early. The other problem is a inconsistent read. It occurs when you read two things that are correct pieces of information but not correct at the same time. For instance, if you read a value from A and then read a value from B to get a value C, if the A’s value change while you are reading the B’s value, your C value will be incorrect. Since the concurrency problems have been around for a while there are various solutions. For enterprise applications two solutions are particularly important: isolation and immutability. The problems accur when two active agents has access to the same data, one workaround here is data isolatio, partitioning the data so that any piece of it can only be accessed by one agent. This technique is used by operating systems to manage the memory used by processes. But what if we can’t isolate all the mutable data? Then we have two approachs: optimistic and pessimistic concurrency control.

Using the optimistic locking Bob and Alice can edit the same file freely and the first one to finish can save it, and when the second one finish it’s commit will be rejected and it comes to how wrote it to to figure out what to do to merge then. With the pessimistic locking whoever checks out the file first prevents anyone else from edit it. This approach can generate a deadlock since the other process who wants to access some locked resource can stay waiting forever and goes to starvation. A good way to think about it is that an optimistic lock is about conflict detection while a pessimistic lock is about conflict prevention.

Patterns of Enterprise Application Architecture - Web Presentation

2012-04-18T00:00:00-07:00

Chapter 4 – Web Presentation

This chapter talk about the presentation layer, which is in the currently days mostly web browser based user interfaces. This bring a lot of advantages: no client software to install, a common UI approach, easy universal compatibility with browsers(sic), and it’s more easy and beautiful to develop then desktop UIs(IMO). Here we will discuss three main view patterns: Template View, Transform View and Two Step View.

Template View Pattern

This is the most common approach to build a web page with dynamic content, the basic idea is to embed markers into a static HTML page when it’s written and when it is served as a response for a request it is markers are replaced for computed content, such as a database query. This way the page can show different contents based on previous computation. As a lot of tools use this pattern, the important here isn’t how to build something using this pattern but to understand how it works and use it. To embed the markers just pick a tool, see the docs and start coding. Currently there are a lot of template engines out there, such as mustache, jinja2, etc. The most popular forms are with PHP, JSP and ASP like server pages. This approach go further then than the basic form, they allow you to embed arbitraty programming logic, called scriptlets, into the page. Obviously it isn’t recommended, since your page becomes incomprehensible for non-programmers and it is a problem when you have to work with designers, other problem is that you starts to mix the application layers and everything will become a mess. A good advice the author gives to avoid scriptlets in the server page is using a Helper Object which containts all the real programming logic. One thing to watch in Template Views is exceptions, if one exception occurs while processing the server page you will have a half processed page that provides decidedly odd output, you can look at how your web server handles exceptions and depending you can catch all with the helper object.

Transform View Pattern

The main idea here is that the data is requested and is provided by a data source layer through a domain model, but the data isn’t formatted to make a a proper web page, using the Transform View means thinking of this as a transformation where you have the model’s data as input and the HTML as the output. A Tranform View is organized around separete transforms for each kind of input element. The tranform is controlled by something like a simple loop that looks at each input element, finds the appropriate transform for that element and then calls the transform on it. This remember me JSON parsers, you input an object and it parses it to JSON. The author uses an XML example to illustrate this example, which was the most common approach when the book was written. The choice between a Transform View and a Template View depends on the team, although the Template View be more used, the Transform View pattern is more portable since you can use the JSON/XML generate as output in any other platform such as Java or .NET.

Two Step View Pattern

When making global changes to the pages appearance becomes hard you can start to think to use the Two Step View Pattern. This pattern deals with this problem by splitting the transformation into two stages, the first on transforms the model data into a logical presentation without any specific formatting, the second converts that logical presentation with the actual formatting needed, this way you can make global changes just adjusting the second stage. With a single stage view approach(such sd the other patterns discussed here) you build a one view module per web page, with a two stage view you have one stage for the model and other for the entire application. Your pay-off is that any changes to the appearance of the site in the second stage is much easier to make, since one second-stage change affects the site as a whole. The pattern isn’t good for design-heavy sites, where each page is supposed to look different because it’s hard to find what can be used in the second stage. Other disadvantage is that there isn’t some many tools to help non-programmers use this approach like the Template View has, so it become hard to use in a team with designers.

Conclusion

I believe most of us use a Template View framework in our day to day work and is already used to it, but its good to know there is other ways to deal with view rendering and stuff, and how this works internally, because how knows when you gonna need use something like this?

Patterns of Enterprise Application Architecture - Mapping to Relational Databases

2012-04-11T00:00:00-07:00

Chapter 3 – Mapping to Relational Databases

I particularly liked this chapter more then others, not because of the patterns described in this section(there is a lot of them) but how it describes the how and why there are some problems with creating/using an ORM, while reading this chapter you can identify several patterns cited through the text and think like ‘wow, the way hibernate/activerecord/blah approachs data manipulation is a pattern called X’ and see the work arounds it does to deal with common object oriented practices like inheritance that mess up and are unviable to simulate/map in relational databases due normalization. This chapter also gave me a more deep view about relational databases, since my experience is most with the nosql ones, since I always have avoided sql and its third party functions(which I always forget) as much as I can. So for this chapter I will focus on the problems(and its alternatives) for this layer.

The Behavioral Problem

When we think in OR mapping the first thing that comes to mind is how the classes are mapped to tables and how to relate it. If you load several objects in the memory and modify them you hae to keep track of which ones you have modified and make sure to write all of them back out to the database, this gets more and more harder when dealing with several objects, as you read and modify them you have to ensure that the database state you’re working stays consistent, so if the object X is already in memory you can’t pull out the same row again and modify it. The pattern used to solve this problem is called ‘Unit of Work’. It keeps track of all objects read from the database together, it also handles how updates are made to the database, instead of the programmer call some save method it tells the unit of work to commit the changes(it remember me hibernate). This pattern also takes care about the problem of loading the same row twice, each time you read some data, you check if this data are already in the memory, to help with this task there is another pattern called ‘Identity Map’, it’s to ensure the uniqueness from data in memory and should not be used as cache or to improve performance, but this approach leads to other problem, in the OOP it’s normal to have have several objects which interacts with others, this interaction can be called object graph and as the models complexity grows the graph grows as well and when you try to pull this from the database what comes to you is a bunch of joined tables, which can turn in a bottle neck in the system, so there is another approach when it becomes a problem: The Lazy Load pattern. It is a object that doesn’t have all the data, but knows how to get it if you need just keeping references, it acts like a pointer, so it avoid loading unnecessary data in the memory.

Mapping Relationships

The biggest problem here is how objects and relations handle links, which lead to two problems, the first is that there is a difference in representation, objects handle links by storing references that are held by, for instance, memory addresses, but relational databases handle links by forming a key in another table. The second problem is that objects can easily use collections to handle multiple references from a single field, while normalization forces all relation links to be single valued, this leads to reversals of the data structure between objects and tables. If an object has a collection, you need a query to find all the rows that link to the id of the object and it gets worse when you have to add or remove from collections. The pattern used for inter-object references is the ‘Identity Field’, which is simply keep the row’s primary key as an attribute in the object, so you can easily access it’s row.

Inheritance

This is another kind of hierarchy scheme that causes relational databases headaches, since there is no standard way to do inheritance in SQL this kind of relationship needs to be mapped too. For any inheritance structure there are basically three options. You can have one table for all the classes(Single Table Inheritance pattern), one table for each concrete class(Concrete Table Inheritance pattern), or one table per class in the inheritance hierarchy(Class Table Inheritance pattern). The trade-offs of this approachs are all related to data duplication and speed of access. In the first case the biggest downside is the wasted space, since each row has to have columns for all possible subtypes and this leads to empty columns. The second one avoids the joins allowing you to pull an object from one table, but if one super class changes you have to remember to update all the other tables which inherits from it. The third one is the simplest solution, but it needs multiple joins to load a single object, and too many joins reduces performance. There is no best solution here, you have to analyze your situation and pick the best fit.

I still want to talk about Metadata, DB Connections and other interesting points from this chapter, so I will split this post in two and talk about this in the next one.

Patterns of Enterprise Application Architecture - Organizing Domain Logic

2012-04-04T00:00:00-07:00

Chapter 2 – Organizing Domain Logic

This chapter describe several ways for how to organize the domain logic and it relies into three primary patterns: Transaction Script, Domain Model and Table Module. Describing each approach and its biggest advantages and disadvantages, and showing how it interacts using other patterns like Gateway, RecordSet and Data Mapper.

Transaction Script Pattern

The simplest approach to organize domain logic is using the Transaction Script, this pattern is essentially a procedure that takes the input from the presentation, processes it with validations and stores in the database. It then replies with data to the presentation layer. The fundamental organization is of a single procedure for each action that a user might want to do. You can use classes instead of procedures to use this pattern in an object-oriented fashion. The most common is to have several Transaction Scripts in a single class, where each method defines a subject area of related Transational Scripts. To identify the TSs you can think as each database transaction can be turned into a TS. The biggest advantage is its simplicity, organizing logic this way is good for applications with only a small amount of logic, this helps keeping the code clean and understandable, but increasing the complexity a amount of logic it keeps hard to keep it in a well-designed state, other problem to beware is the code duplication that could happen since the transaction seems to be fairly similar. When the domain logic gets more complex its time to use the Domain Model pattern.

Domain Logic Pattern

This pattern has an OO style(which can be implemented as an Entity Bean in J2EE apps), it divides the logic into objects, in the simplest form, it looks like one object for each database table. A rich Domain Model can look different from the database design, with inheritance, strategies and other patterns, this approach is better for a more complex logic but its more harder to map to the database. A good ideia is to use a simple domain model with the Active Record pattern and the Data Mapper pattern for the complex ones. Since the bussiness logic can change, it’s importante to be able to modify, build, and test this layer easily, so you’ll want the minimum of coupling from the domain to other layers. A common concern is about overloading a domain object, you’ll notice that some behavior is similar to every model and it could be good to isolate it in other object. The problem is that it creates code hard to maintain, and the other developers tend to not see it in the model and duplicate the code, and the duplication can quickly lead to complexity and inconsistency. So, the advice here is to only fix the bloating in the models when, and if, it becomes a problem.

Table Module Pattern

One of the problems with the Domain Model pattern is the interface with relational databases, as a result is needed a lot of work to pull data in and out of the database as the complex of domain logic grows. The Table Module pattern organizes domain logic with one class per table and a single instance of a class contains the various methods to act on data. The main difference is that if with you have various objects using the Domain Logic pattern each one is responsible for itself, while using the table module, you will have to deal just if one instance to do the work for all the objects, it acts like a facade where you can do the CRUD and the object is unaware of the operations. This pattern gives you an interface that acts on the passed data. This pattern can be an instance with a collection of static methods, you can then use this instance to manipulate the data. The word table in the pattern name suggests that you have one Table Module per table in the database, while this is true in some cases it isn’t recommended because the structure of the Table Module doesn’t depends on the structure of the tables in the database but more on the virtual tables perceived by the applications, usually represented with some data structure resulted from some other query.

Conclusion

As all things in software architecture you can choose what to use and how to use it to solve your problem, you can even use these three patterns combined if you need, as the author says, a good solution is implement the Domain Logic using Transaction Scripts on it. So it’s up to you to decide the best approach to solve your problem. Next week I will talk about the Chapter 3.

Patterns of Enterprise Application Architecture - Layering

2012-03-28T00:00:00-07:00

For this week I was asked to start to read Patterns of Enterprise Application Architecture from Martin Fowler, starting with the Introduction and the Chapter 1 – Layering. I’ve already had used this book a couple of times for reference but never had read like this, chapter after chapter.

Introduction

I used grow my interest in a book depending on the introduction section because it’s like an extension of the preface and the author can write more widely about all the contents of the book, showing what it has to offer and this book’s introduction is a good one. The author says more about patterns, going beyond the UML representation or code, with a pattern’s definition and other not technical benefits for who is using/know patterns, for instance if someone says “this class is a Remote Facade” and you know the pattern Remote Facade you don’t need more information about it because you already know what it is for, or if you don’t know you already know what you need to know, so design patterns creates a vocabulary about design. This section also describes how the information is organized in the book, divide in “How it Works”,“When to Use”, “Further Reading” and a implementation example, in its simplest form.

Chapter 1 – Layering

This chapter starts talking about on how this approach works, the most know example is the TCP/IP model which the application layer is built on top of the transport layer which uses services from the layer below and so on, without know there are others layers below the one which is providing service. This give us some benefits: Turns easy to maintain several parts of the code, you can replace one layer with alternative implementations of the basic service without crashing everything.

On the other hand, this approach have some downsides. This layering causes some dependencies between them, for instance, if you change the API of one layer you have to change it in the layer which uses this services, and all these layers can harm performance.

It also presents the three principal layers, which are the presentation, responsible to displaying information, domain for the system’s logic and data source where the communication with databases, messaging systems, happens. But where you separete them depends on the complexity of your system. In systems where there are no users, the presentation is an external interface for a service your system offers. There is just a steady rule, the domain and data source should never be dependent on the presentation, this made easy to replace it for different kinds of presentations. The author also discuss about choosing where to run the presention layer(browser, sure!), putting some concerns on the UX and user needs.

So, that is it for the Introduction and Chapter 1, next week I’ll talk about the Chapter 2 – Organizing Domain Logic.

Hello world and The Passionate Programmer

2012-03-21T00:00:00-07:00

Hello world!

Since one of my tasks in my internship at OfficeDrop is blog about some books I’ve been reading, I decided to start it in a new fresh blog, powered by github pages. There is some work to do here about the layout and stuff, since mine was ~stolen~ from Zach Holman, but I’ll do it later, I’m kinda busy right now.

The Passionate Programmer

So, for this week, I was asked to read “The Passionate Programmer”. This is a MUST read for any programmer, in this book, Chad Fowler lead us through 53 advices on how to make a remarkable career in software development. After each advice he says what you can do to put it in practice. I’ll list some advices I liked below and write about what each one means.

2 – Supply and Demand: On this advice, Chad talks about demand on determined technology and how this affects your job. Simplifying, it’s like: if it’s paying well Y U NO LEARN IT? There is no space in the market for fanatics, I mean, there is but you’ll not give you a chance to evolve.

7 – Be a Generalist: This advice tells that a programmer skills should transcend technology platforms, and not think about this like a “jack-of-all-trades but master of none”, you can(and you should) know about the development environment works, how to setup the web server, and all that stuff, because it’s all about your job.

8 – Be a Specialist: This is one of my favorite ones, it tells to not use the word specialist as an excuse to limit your knowledge, you can’t say you’re a Java specialist just because you only know Java, to self titled yourself as a Java specialist you have to know the Java platform deeply, and not only know how to use the standard API.

9 – Don’t Pull All Your Eggs in Someone Else’s Basket: Don’t limit yourself in your goals, Chad tells an interesting history about one of his co-workers which said his career’s goal is to be a J2EE Architect, so made a good question, what if the J2EE become obsolete? It’s the end of your career? Don’t build your career around an specific technology.

15 – Practice, Practice, Practice: Your programming skills grows as much as you practice it. But it’s not just doing always the same thing or solving the same problems, you have to practice at your limits, try harder problems, implement harder things. You can take it to know more about your programming language of choice, know about the streams and networking libraries available, etc. It’s a win, win.

30 – Say “No”: The idea is simple: Just say NO, when you can’t do something or when the deadline is too short, it’s better then say yes and don’t do the work, as he says “Saying yes to avoid disappointment is just lying.”

52 – Better Than Yesterday: Just ask yourself everyday: “What can I do today to be better then yesterday?”. The awesome thing here is that it’s apply about everything in your life.

So, this is it for the first post.