Opting for a domain-specific approach versus data-driven design with code igniter

[eluser]Jay Callicott[/eluser]
I am in the midst of reading "foundations of programming ebook" here: http://codebetter.com/blogs/karlseguin/a...ebook.aspx by a .NET guy and wondering if I should be using a domain-specific approach.

I build a lot of applications, in 2 years I've built 30+ live state government (many big) applications using code igniter. We're moving to .NET but thus far it's been all CI.

I use the MVC approach and I have to say it's not bad. But it does get me into trouble sometimes. I built my own "poor man's rails-esque active record" tho much simpler that i use which kind of binds a model to a database table but of course I cheat bc often it will do operations across other tables, sometimes other databases and other models which can really muddle things up. It's bc often I can't make up my mind as to whether the model is a representation of that table or a more abstract model of a domain like this book talks ab. Like for example you could have a table called "users" but usually the user model involves alot more than just the interaction with that table.

I am sure there are some projects out there that do object-relational mapping in CI - I'm not really interested in that unless it's really good. I haven't been impressed by the CI 'plugin' contributions.

My thought is maybe I need to map out objects in the 'domain' space using my libraries folder and then initiate models through those libraries and in the controller only interact with the libraries instead of directly with the models which is what I do now. So instead of a user model I would have a user library and initiate the user model and any other model that dealt with that problem space. My user model would be much cleaner bc I would probably only include functions there that interacted with the database. Often there are other things you're doing such as login/session management, validation, interacting with files, etc that have always felt 'awkward' in the user model.

What do you think? Am I missing something really obvious? Are other ppl doing this?

[eluser]Randy Casburn[/eluser]
Hi Jay,

I don't think I've seen the book. Maybe I will...who knows. That said, what a great question that a person usually must earn the right to answer. So consider me to be Mickey Mouse with no credibility whatsoever.

I just returned from a trip in New York city where I spent a week with a group of software engineers and business analysts helping them through a very similar struggle. Three weeks ago I was in Dallas with a gang from CitiGroup answering the very same types of questions. Not nearly as specific as yours but along the same axis if your will.

Many coders use what I call the coder-loop development method. They 1) read high-level user requirements in an e-mail, 2) Code from the e-mail, 3) repeat step 1. This may result in the "job getting done", but the downstream effects are costly, even in a one person organization. I try desperately to get coders to step away from the keyboard as soon as the requirements hit the inbox. So in that same vein, I would like to recommend you "step away from the keyboard" too. Don't think about "mapping objects" and "library folders" just yet. I would rather you find out ways to feel less "awkward" first.

As an example, you might consider building Use Case Models and descriptions. I know that many folks will puke on this idea and I'm OK with that. What you'll find by doing this is an abstract idea of where your functional "domains" lie within your applications. They won't look like "libraries" yet, but they will make sense in relation to what your PM or stakeholder is asking of you. Next, you'll want to mock up your UI and have all your data entry fields documented. It's best to do this on paper...stay away from the computer.

It is absolutely vital that you consider creating both Activity diagrams and State Diagrams next. Both of these allow you to create "guard conditions" that represent all of your error conditions, all the conditional flows, all the validations for your UI data entry fields, etc. This is not as hard as it sounds and all it really does is allow us to document all our conditional operations and error conditions. We have to do this anyway, this just becomes our documentation.

OK... It should be obvious to you that some questions about data must be answered at this point in order to create these diagrams! The key here is that we are not creating a database design here. We're asking the stakeholders what data they need in order for the system to function properly. So now, then, you should realize we've just transitioned BACK into a data driven environment. But let me explain something very subtle that I've done along the way...kinda sneaky...

A lot of effort (money) has gone into gathering and defining Business Rules. Business Rules are made up of defined terms (these show up your Use Case Scenarios), and facts that are established via your UI mockups, and some constraints and truths which are proven in your Activity diagrams and your State Charts. All you have to do is gather up these rule sets and document them one time. These rules will apply the same way to all your applications. You likely won't have to repeat all this work again...ever.

Once you have all that, you can apply these to a fresh data model and either validate the database design you already have or create a new db design.

Now here is where it all comes together into a cohesive design that you can code. The next step is to build a UML sequence digram in which you put all this together in a step-by-step flow from one object to the next. This diagram will make clear to you what must fit together, what must be apart, what relationships can be constructed within the API, etc. Now we're talking "libraries" and "folders" ;-)

The cool thing is that once you have this done for one project, it's done for most. Do this for your first .NET project, you'll thank yourself for the rest.

=========
I guess I could have said..."develop from the top down instead of the bottom up"...

I hope you find this a tiny bit helpful.

Randy

[eluser]Jay Callicott[/eluser]
Your answer has a lot of structure to it and I think it's valid where appropriate but for small to medium projects some of it is overkill. I wish we mocked up everything at my full time job like we do in my part-time job. The 2 approaches are very different. At work we rarely get any mockups but often get pretty detailed specs from the PM with sometimes a UML diagram which is certainly helpful. I think visually so I prefer PSD mockups like we do consistently with my part-time business.

The thing is, I've done so many of these things, many times 80-90% of the application triggers things that I've already done, ok we have a data set, users and needs reports and crud operations on this/that data. At least with govt apps alot are renewals, workflow apps, searches, etc - similar enough that me creating a lot of upfront documentation would be overkill. On the other hand with my part-time business we're building more innovative sites that have more components we haven't done before and are visually much more carefully constructed so we do a lot of mockups and back and forth on that even tho unfortunately I usually have less written documentation to go on. Even then those sites I do with drupal, much that needs to be done is a matter of figuring out how many want it to look and feel versus having to worry as much ab the structure since we use a lot of contributed modules.

At my work to our credit or to a fault we can get things out very quickly which is a strength and a weakness. And we have a lot of structure in our deployment process but we are efficient enough we can still move things quickly. So in a nutshell a ton of documentation isn't usually going to happen.

What I really strive for is clarity in my code and more inline documentation to help maintainability. I use a lot of convention, I share a lot of plugins/libraries/helpers amongst all my apps which all 30 run on 1 install of CI which I had to slightly hack to share libraries.

Altho using object relational mapping is intriguing I fear it will look too much like just an extra step calling a lot of delegate functions. I'd really like something like .net's hibernate or rails activerecord which I think would accomplish what I'm aiming for. Maybe Code Igniter has something similar.

[eluser]Randy Casburn[/eluser]
Pretty much the response I expected. Please consider what you've said above...

...many times 80-90% of the application triggers things that I’ve already done...

This is what everyone does. This is exactly what I think you should take advantage of in terms of mapping your resource relationships, and my goal from the beginning. Do it once and use it over and over again. You'll realize when it's best to use Drupal, when it's best to use CI, when it's best to use what ever, and you'll understand your object relationships.

Altho using object relational mapping is intriguing I fear it will look too much like just an extra step calling a lot of delegate functions. I’d really like something like .net’s hibernate or rails activerecord which I think would accomplish what I’m aiming for. Maybe Code Igniter has something similar.

Unfortunately, no. At least not to the depth you expect.

Maybe Code Igniter has something similar.

After 30+ projects with CI I would expect that you would realize this.

My hope was to get you to see that going through the pain once would allow you to see the relationships between your components, modules, interfaces, objects, or whatever else you want to call your stuff outside the bounds of any constraining software system such as .NET or CI or Rails or any other "framework" that puts blinders on YOUR ability to see how to build your system. As soon as you start putting code into one of these systems you have to conform into it's rigid/jello way of doing things. That clouds your thinking and binds your freedom as a developer.

Allow your expertise do the constraining...not the frameworks. The frameworks can all be shape shifted, molded and adapted to our needs right?

What I'm suggesting can make you development even MORE efficient than what you suggest yours is already. That may stretch your imagination a bit, but to experience this is quite extraordinary. Some folks actually call it -fun-. The buzz words go away and the pragmatic realities of "doing better" feel good.
-----------

Either way, thanks for listening to my Mickey Mouse stuff. ;-)

Randy

[eluser]Rick Jolly[/eluser]
Just love these thought provoking discussions.

I'd resist having a user library that interacts with models. As you've mentioned, libraries should be shared. Models are application specific. So once you tie a library to a model, it can't be reused. You could call libraries from your model though, if it helps. User session and file data is still data, so I think it belongs in the model. Maybe, if it makes sense, you could subclass a parent user model with more specific classes to deal with user sessions, etc. Or just call models from models.

I agree that, at least for small projects, the more experience I gain the less planning is necessary. The solutions to repetative problems come naturally. Finishing projects quickly is a competitive advantage.

Have you looked at Doctrine for object relational mapping? That may be the best php ORM available. Still, I prefer the ease and flexibility of CI's database class or PDO.

Allow your expertise do the constraining...not the frameworks.

Sometimes the rigidity of a good framework is a blessing - it is designed to force good code. But with the experience of 30+ projects, you're in a position to extend, improve, and make a framework your own.

[eluser]Randy Casburn[/eluser]
[quote author="Rick Jolly" date="1219270453"]

Allow your expertise do the constraining...not the frameworks.

Sometimes the rigidity of a good framework is a blessing - it is designed to force good code. But with the experience of 30+ projects, you're in a position to extend, improve, and make a framework your own.[/quote]

My point exactly...but only because of the level of experience projected in the post.

This one point is what makes CI great for some and horrible for others. Those with experience LOVE CI because of the freedom. Those with no experience find it so "unconstrained" they often "don't know where to begin" or we see "can you tell me where to put my queries" kind of questions. You know what I mean.

When I look at my models of CI and some one asks "how would you do...." it is just crystal clear where it fits to me. It works for me because I'm so very visually oriented. The entire conundrum of arguments about MVC and breaking this preserving that and all the academic crap completely falls into the trash can. But then again, I'm solving problems for businesses and people that run businesses, I'm not solving problems for a computer. Maybe I look at things differently. The stupid computer is just a tool to get all that done.

@Rick - I too like these think pieces ;-)

Randy

[eluser]beemr[/eluser]
[quote author="Jay Callicott" date="1219212051"]My thought is maybe I need to map out objects in the 'domain' space using my libraries folder and then initiate models through those libraries and in the controller only interact with the libraries instead of directly with the models which is what I do now. So instead of a user model I would have a user library and initiate the user model and any other model that dealt with that problem space. My user model would be much cleaner bc I would probably only include functions there that interacted with the database. Often there are other things you're doing such as login/session management, validation, interacting with files, etc that have always felt 'awkward' in the user model.[/quote]

To bring it back to the OP, I think that's an interesting approach. Currently, I'm using the library Active Record Class Mod 0.7 to give me Rails-like relationships in my models. However, now that these relationships manage so much of what a normal CI model would perform, I find myself with very thin models and a library that contains most of my data interaction. It's not that big a problem since the Active Record Mod code is still very readable, but like you mentioned before, it feels awkward.

I might just follow your suggestion and try making a "user" library that contains "model"-type behavior for all of the models that actually make up a full "User".

So, what are the big frameworks behind domain design? It's my understanding that .NET is trying to release its own MVC pattern. Are they giving up on domain-based design? Is there an Open Source community that pushes the domain approach?

[eluser]Rick Jolly[/eluser]
[quote author="beemr" date="1219278840"]
I might just follow your suggestion and try making a "user" library that contains "model"-type behavior for all of the models that actually make up a full "User".
[/quote]
The more I think about it, the less sense the library approach makes. Unless the library is generic enough to use with all models, it can't be reused so it doesn't fit my definition of a library. Maybe this is just semantics, but if you're dealing with data, use models. To organize and breakup your user model code, you could go with composition or inheritance. I prefer inheritance.

[quote author="beemr" date="1219278840"]
So, what are the big frameworks behind domain design? It's my understanding that .NET is trying to release its own MVC pattern. Are they giving up on domain-based design?[/quote]
What does that has to do with "domain specific design"?

[eluser]beemr[/eluser]
[quote author="Rick Jolly" date="1219282392"]
What does that has to do with "domain specific design"?[/quote]

Just wanted to get more info from the OP:
[quote author="Jay Callicott" date="1219212051"]I am in the midst of reading "foundations of programming ebook" here: http://codebetter.com/blogs/karlseguin/a...ebook.aspx by a .NET guy and wondering if I should be using a domain-specific approach.[/quote]

Also, when you talk about inheritance, are you talking about controller inheritance, or is there a way for model inheritance?

[eluser]Rick Jolly[/eluser]
[quote author="beemr" date="1219284409"]
Also, when you talk about inheritance, are you talking about controller inheritance, or is there a way for model inheritance?[/quote]
Ya, model inheritance. Of course any class (that isn't marked as final) can be extended. It's just that, when going beyond what CI offers, you have to use a php include/require to include the parent class first.