I’ve encountered the idea of Command objects before. Simply put they represent actions given some input that do something. In essence, they, in some ways, replace your actions on controllers so you can increase your reusability in your code by isolating your logic in a separate unit. As an example, you could call a command from a job or a different service interface if the command’s job was to create a blog post.

The way Commands are executed are through the Command Bus. In truth, the Command Bus really isn’t necessary and you can simply instantiate a Command and run it’s handle() method directly if you implement the SelfHandling interface. On average, you probably will use the artisan make:command to generate a command and this will automatically create the skeleton code with the SelfHandling method implemented.

For me, I felt that this mechanism, while having a good intent, feels as though it’s been lazily implemented. I can see why from a high level abstraction principal how one would desire to separate the Command data from the Command processing. However, in practice the Command object itself is merely a useless Data Transfer Object (DTO) and doesn’t truly have much reuse by itself in my experience without the handle method directly attached. I know that part of the intent is to be able to map Request Forms onto something like a DTO which can then be applied to a Model. But at this point, it feels as though the extra DTO layer provided by the isolated Command object just becomes too cumbersome.

Another area where I feel suffers in weak implementation is the whole Command Bus and notion of a pipeline. I suppose I get the main idea of how these two things ought to work together. However, the documentation detailing exactly how to combine these elements in practice is really lacking on the Laravel website. Part of the problem is that Commands in design are not supposed to return anything (this is regarding the handle method). If you examine the dispatch() method though, you can return a value once you execute your command. So that part of the design really confuses me.

Also, you have the pipeline which in my mind is similar to how pipes in a Unix system work; that is, you’re chaining commands together where the output of one command somehow gets mapped into the next one. However, if the recommended practice is to avoid having a return type, this design becomes null. So how exactly can you map the output of one command into the next one?

When I did some research, I found some hand rolled solutions that took the commands and chained them together. But why isn’t this better highlighted in the native architecture? Is this something that the developers are still working out?

I think part of the problem is that Commands as of now are pretty simply in essence. You pretty much provide a constructor where you toss in any inputs into the command. Then you process them through the handle() method. There isn’t any object returned the way you can return a view in a controller action. I think if there’s one major aspect that Command objects need to revisit in terms of architecture is to force people to implement some sort of return type such another DTO with information like error messaging, additional data similar to some RESTful interfaces and flags for allowing the next command to continue processing. Then provide mechanisms to inject things like logging, transactions, etc.

Right now, the way I handle dealing with command chaining is to avoid it altogether. I really want the people designing Laravel to come up with a standard architecture that improves upon this idea. I know for 5.1 they will be changing commands into jobs. While this does improve some clarity in the intent of what a command is supposed to do, this really seems more focused on the console aspect. We still don’t get some form of chained processing, which is what I really would like to see.

Rather than chaining commands though, what I do is fire Events. In some way, it’s almost like command chaining except you’re essentially trying to inform the system that a particular thing is happening. This part of the system gets a little tricky in terms of design because it may feel confusing at times when one ought to use commands over events and vice versa.

So the way I think about commands vs events is that commands are things that I want to happen right now. On the other hand, events are something that happened and I’m shouting it out to the world to react to it. So a great example of this occurs when a new user registers. In most systems where a user registers, the big parts of the processing are first validating that the data is valid then storing that data. Here, you can use a Request object to handle the form validation. The command can then do the job of persisting the data. In most cases, that might be only a single table, but it also might affect things such as adding a role to the user, signing that user in, adding notification settings for that user, etc.

In this situation, where do we draw the line of what to put in the command object? My rule of thumb is that if there’s some sort of immediate required feedback, then put that part of the processing into the command. Here, persisting the user’s information into a users table as well as adding a role to their account so that they can be auto-signed can all be part of the command.

However, sending an email to confirm that the user has created an account does not require immediate feedback and can be put into a background job. So your event would be just to inform the system that a user just has been created. You probably would store the successful results of the created row into the event because it might contain an id column required for part of the email response.

Like the command object though, the event/event handler has a similar flaw in that the event object itself is just another DTO. I do think it has a little more meaning in the way it can be used since you can queue events. However, the thing I dislike is just the somewhat informal way of creating events and their respective handlers. You’re still using a more or less useless object to transfer particular sets of data to something else that will process it. This makes commands and events feel as though they overlap in purpose somewhat and a little redundant of one another, not to mention adding the overhead of confusion with more layers that become obfuscated.

The other thing is that like Commands, Event Handlers themselves are not supposed to return anything. One common thread I read is that not having a return type makes unit testing a lot more difficult. From my own experience, this aspect gets compounded once you have Commands firing events that fire even more events.

Lastly, one of the biggest flaws I see in this architecture is the potential for getting into an infinite loop. There really isn’t anything that prevents one from having an event call a command and vice versa. Worse, if you’re in a situation where you designed your system poorly, you have the potential of having them calling each other. And there are times where I can see myself wanting to call a Command object inside my Event handler just because I want to avoid replicating logic.

Overall, I get the architectural desires that these methods provide. However, both need a serious clean up with better recommended practices and perhaps even combining both somehow for cases where the logic in one section needs to be shared somehow.

The post Laravel: The Ugly Command/Event – Handler System appeared first on Kontroversial Keith.

Right now, as I’m learning Ruby on Rails, the thing that strikes me is the notion of how the database ends up becoming a stupid data store. It’s really just an artifact of infrastructure as opposed to the driving force behind a company. In all honesty, I started to become suspicious of relational databases back when I worked for Demand Media and spent time on Livestrong. A lot of problems occurred due to how our Mysql Database would occasionally have issues scaling. My team lead and I started to become extremely frustrated by being tied down through the database layer.

In order to avoid the scaling problem, you end up turning to non-relational methods to handle your problems. For instance, one of our tables at the time was at the half billion row mark. Because of how it was primarily a constant write table, we needed a solution to evolve it. At the time, the solution we ended up going for was archiving most of the data and truncating it. Then when a user wanted to access older parts of their history, we would unarchive it upon request.

But note the language I’m using here. I’m trying to avoid using database specific terminology to describe a problem and create an answer. But that’s where you need to think more on an abstract level rather than a fine grained level such as a database row/table/column at times. And that’s where you need to move from the data layer to a business requirements mind set.

Now, I’m certain that most people in tech will all agree that solutions must be centered around business requirements. Although that’s certainly a common bond, everything ends there since people end up doing work arounds. Quite often, these work arounds exist as a result of the inflexible structure and/or nature of the database. Of course, applications also have their limitations but databases tend to be more rigid because of data.

That’s where I like how systems such as Rails have certain control over more static data elements of data through notions of migrations. Also, things like Rails seem more fluid in design because you’re attempting to do more abstractions. For instance, I encountered the :references value which allows one table to hold a relationship (one-to-many) to another. Rather than bothering with all the details of the database such as foreign keys, indexes, constraints, etc., you allow the application layer to manage that.

Part of the reason why I like this is that the technical details for an application can take away from significant development time. Having the application manage those aspects alleviates developers from useless duties and allows them to focus more on business logic. Anything that saves on time is a good thing for me.

One thing that I have noticed as the industry continues to grow is that the role of the DBA is slowly diminishing. I feel that DBA came about as a result of Oracle being so dominant early on and existing solutions not having an open source, well documented alternative. In turn, DBAs ended up becoming extremely powerful, commanding high salaries and often times enacted fairly draconian policies with regards to data. More than that, they would attempt to control the business layer by forcing developers to house all their business logic within the database. In turn, that forced applications to utilize incompatible SQL and stored procedures and providing little flexibility as new cheaper and potentially faster/better solutions appeared on the market.

Unfortunately, you had varying qualities of DBAs. Some were actual computer science students who knew about application development. However, others seemed more like people who just had fancy certifications but knew and potentially cared little for application development. Instead, some of those more poisonous individuals would utilize their power as DBAs to have all decision making processes filter through them. If they lacked the passion and/or knowledge of application development and also were difficult people (and quite a few that I’ve encountered were), the application development process would end up becoming a huge, unnecessarily bureaucratic nightmare.

The thing is that as a developer I want to build things without the issues of unnecessary forms, reviews, etc. to get to an end solution. As an architect, I want to develop solutions without thinking about artifacts upfront. I want to focus on the problems then break down the problems rather than starting with say a table and defining all the columns. Once you go down the latter path, it becomes a slippery slope because you end up working around the table as opposed to the problem and making that solution more scalable.

That isn’t to say that data isn’t important. Of course, these days it becomes a huge part of the genetics that compose an organization. But in the application development process, I really do not like it being the center of attention. Similarly, I think picking a technology in advance and trying to fit it with a business problem is equally wrong. Focus on the problem first.

Lastly, I talk a lot about Ruby on Rails. Although I decided to pick Rails for my next project, it’s mostly because I want to learn about it and how to really utilize it. That is somewhat different than say arbitrarily choosing Nosql as my data store because it’s the latest and greatest. If it’s a learning situation, then choosing the technology in advance is fine. But don’t play with others’ money if you have the chance.

The post Data Driven Development: The Mistake I Made By Moving Towards This appeared first on Kontroversial Keith.

Although I’ve talked in the past about how I prefer the notion of MOVE (models-operations-views-events) over basic MVC. There’s an even deeper problem that stems not necessarily from the inability to segregate code properly, but something that seems endemic to most programmers: the inability to understand domain modeling.

I think it’s this issue which is at the core of a lot of companies’ architecture problems. And it’s not an easy idea that can go away in a day either. The issue lies in understanding domains or even more fundamentally the basics of OOP.

This topic was brought to my attention when a former co-worker of mine asked me about some OOP issue he was struggling with. Although he wanted a simple answer, I could not provide one because I feel that OOP, domain modeling and setting one’s goals in all of this are not trivial.

OOP and domain modeling are all about understanding the problem you’re attempting to solve. When you start to think in coding constructs and other structures or design patterns before attempting to address the problem, then you’ve already failed in grasping some of the basics.

His issue was that he wanted to simplify something that sounded like a POJO in PHP. It took me some interrogation to probe what exactly he wanted to do. But that’s the way I think about such things when trying to educate someone who might lack the experience level in modeling/OOP design. It’s not so much to me about creating something simple or some killer coding methodology. I need to figure out what I want to accomplish first.

When it comes to corporate systems, things are even more difficult because of how businesses tend not to truly understand the thing they are attempting to solve. If I don’t know the thing I’m attempting to build, how can I accurately come up with something that models the problem I want to solve?

I had an interesting discussion about this subject with another coworker who had a better grasp of OOP. In that discussion, I talked about how a model of a tire might be different for an auto manufacturer compared to a tire company. For the auto manufacturer, the car itself is the domain object that I’m modeling while the tire is a component of the car. The tire might not necessarily be the focus of the car so it might not have much meaning when you take it out of the domain. However, compare that to the tire maker where the tire is everything. These two examples show at a high level the notion of object composition. But where things become relevant all depends on how the business sees it.

And that’s where the difficulty lies and where domain modeling becomes exceptionally difficult. Domain modeling here isn’t just about exposing a bunch of setters and getters. It’s about exposing the functionality that provides inputs and outputs to that domain object. If we go back to the car vs tire example, one could say that the only thing that the car domain object would care about is whether or not the tire is attached or has a flat. The tire domain object might provide inputs like a gauge that talks about the air as a feedback system back to the car’s computer. However, the car wouldn’t care what type of rubber the tire is made of nor would it care about how the tire was originally made. Those are details of the contract that the tire manufacturer does not need to provide but would hide in their API.

Then when you get into many companies, especially at the web level, I feel that these ideas become lost to them because they’re too focused on some 3rd normal form database or other document storage types of systems as opposed to asking deeper questions to create a more coherent architecture. At that point, MVC only becomes a convenience to hire developers rather than a strict enforcing methodology with principles for which developers would be able to engender well thought out objects.

I think a lot of the problem ends up occurring because of the database artifact quite honestly. Web technologies and conventions have royally screwed up good programming practices because of how databases are structured. People often worry more about details like caching, database handlers, etc. as opposed to well formatted APIs. The result ends up becoming these cludged up systems where the code is disorganized, inconsistent and bulky with little hope for re-use.

The other thing that came to my attention in talking to my coworker was eliciting the target audience of the code base. It ended up being a personal project, so I told him that there’s two ways to go about doing things: 1) if you just want to get something done, fuck it. Don’t worry about structure or coding methodologies. Just make sure it works; 2) if you’re doing this to improve your knowledge of coding by giving yourself more practice, be strict on what you’re doing. Attempt to adhere to good principles and try to understand why certain principles, albeit seeming painful, exist. In short, think about the problem you’re trying to solve, not the way you’re solving it first.

Of course, at the corporate level, most people do not receive this luxury. Typically, developers are out of time and must resort to desperate programming practices. And realistically, the thing they are attempting to build will be vague so modeling such a thing would be akin to taking my mom to the acupuncturist. But I still feel that you should always first try to establish the problem you’re attempting to solve before trying to solve it. Figure out the inputs/outputs, the processing that occurs as a result of the inputs that produces an output, determine the adjectives or other descriptive aspects that make up the object’s details and description as well as it’s connections to other related objects and the actions you want to expose. If you think like this, your code will start to feel more elegant and scale better in the long run because you’re working against an API not just the details of a problem you think you’re attempting to solve at the moment. And that aspect is good code.

The post Domain Modeling: Why Most Architectures Suck at this Level appeared first on Kontroversial Keith.