Jeffrey Palermo 7:36 pm on July 15, 2007
Tags: Coding Principles ( 26 ), Featured ( 16 ), Managing ( 12 ), Tips & Tricks ( 43 )

Focus on the core: the most important part of the application

Technologies are coming and going faster than every before. In this environment, how can we provide companies with a good return for their software investment. Looking back, J2EE was all the rage. Software executives were banking on J2EE and making significant investments. The same thing happened with COM+, ASP 3.0, etc. Managers were projecting significant savings by using these. Now, where are the savings. Many applications written with these are being rewritten in newer technologies.

Why? Because the applications had no core. By core, I mean, the center of the application that describes the business domain. Typically, these are classes and interfaces. Creating classes using COM+ or J2EE doesn’t an application core make. The core doesn’t care about surrounding technology. The core is your domain model. By its design, it’s the most important part of the application, but, done well, it’s portable.

Look around and see if you can relate to this: A software team focuses much energy on making the database as good as possible and they create stored procedures to pull back the data as quickly as possible. They also consider the use cases of the screens that are necessary. Using technology X for the presentation, they make database table designs and stored procedures that return exactly what the screen needs to show to the user. Perhaps J2EE or COM+ is used in the passage of information from the database to the UI. Perhaps Enterprise Java Beans for COM+ components perform some transformation or calculations necessary for the screens.

Take a step back and remove the screens. Remove the database. Is there any application left? Can you point to any business rules or domain concepts left in the application after the presentation and storage components are removed? In my experience, I’ve had to answer “no” more than once. This is absolutely the wrong way to develop software.

Software systems should be resistant to climate change. The technology climate is always changing. The core is the most important part of the application, and it should be insulated against changes on the outside. Over time presentation technologies have changed many, many times. Data access technologies haven’t sat still either. We still have the relational database, but the manner of using it is constantly changing.

Software health check: Take away the code used to talk to the database. Take away every screen. You should still have an application. You should be left with your application core or domain model and domain services. Everything should be intact.

Handle changes in technology gracefully. If your application has a healthy core, you will be able to upgrade to the next-generation UI. You’ll be able to change your data access to use LINQ or an ORM without much impact. If you don’t have a healthy core, any change in technology requires almost a wholesale rewrite.

Any software system is a large investment for a company. That software is expected to last a LONG time. By focusing on the core of the application (domain model), the software will be able to weather changes in the technology climate. By creating a healthy core, your software will be able to drop and adopt technologies as necessary. Let’s stop rewriting and rewriting and start creating healthy software.

The inspiration for this post came from Jim Shore’ s thoughts.

Jeffrey Palermo 12:42 am on July 16, 2007

An example I can pull from a project follows: The UI needed some information in an xml document. The information was part of the domain model. It just need to be translated from an object graph to the proper xml structure. The approach taken by the developer was to create a SQL stored procedure with SQL Server 2000 and use the “For Xml Auto” capability to return the exact xml needed by the screen. The worked initially, but it completely bypassed any application core or domain model. The database was coupled to the needs of one specific screen. Note that this isn’t compile-time coupling. It’s semantic coupling, and this type of coupling can be harder to manage.
Gil Zilberfeld 1:53 pm on July 16, 2007

I agree with the principal. And, there’s also a lower level connection (at least for maintainability) that we need to consider.

We just did a review of an application we developed starting in 2002. This was .Net 1.0 which went to 1.1, and then 2.0. We looked at what can be reused from this app to others that we are building now.

This application has a data model (no database, just file system), that did not experience the transition to 2.0. Its collections remained ArrayList long after Generics were introduced.

So the data model (the core) itself stands. However, it’s not as versatile as today’s collections, and we dropped it from our reusable component list. It would be easier to maintain newer versions.

Our core, because it was tied to a technology (.Net 1.1) at the lower implementation level, would be dropped the next time. And it will cost us again if Microsoft decides to change the underlying technology.
Jeffrey Palermo 3:15 pm on July 16, 2007

@Gil,
I’ve thought about this even when switching platforms. Now, the underlying assumption is that you go from one object-oriented platform to another. Let’s explore moving from C# to Ruby. I may move by asp.net presentation from ASP.NET to Rails. I may move my data access to Rails ActiveRecord.

What doesn’t need redesigning is the domain layer, the core. Yes, the syntax is different, and the code needs to be retyped, but the concepts remain the same, and the interfaces to the outside are the same. It’s a mere migration to a different syntax than a wholesale rewrite. Retyping the syntax in Ruby goes very quick, and the core of the application is intact. The remaining steps are platform-specific services surrounding the application.

I see it being similar with .Net 1.0 to .Net 2.0 and to 3.5 next year. Sure, some of the syntax will have changed, but business concepts are the same. Sure, I’ll change my ArrayLists to List, but that’s a small syntactical change. Move to LINQ for data access? Not a problem if my core is independent of data access concerns.
SBC 5:57 pm on July 16, 2007

Focusing on the core entails knowing the business well. Unfortunately, relatively more ‘architects’ & sys designers don’t posess that knowledge. This may be due to the training and/or the company (development )environment.
Liang 4:33 am on July 18, 2007

I totally agree with you. But it is very hard. Technology comes and goes. From 2000, we rewrite the client application with VB6, ASP, ASP.NET1.0, ASP.NET 2,0. Now it comes Ajax. Database will stay relatively longer. How do you convince your boss or other team members that putting all of the logic with C# 2.0 will take longer. C# 3.0 is on the coner already.
Jeffrey Palermo 1:12 pm on July 18, 2007

@Liang,
I don’t think putting logic in C# 2.0 will take longer. I think putting application logic in a domain model on an object-oriented platform is the way to go. While the database tables will probably stay around for a long time as well, code written in procedures tied to a database platform will not be portable.

C#1.0, 1.1, 2.0, 3.5 is nearly frictionless as far as the core domain model goes.

As far as convincing, it’s tough, and it depends on the manager.
Liang 4:49 pm on July 18, 2007

Thank you, Jeffrey! I understood your points. But when putting business logic into domain model, it still depends on language and platform. Some code has to be rewritten if platform changes. For example, if we need to take advantage of .NET 2.0 Generic, or LINQ in C# 3.0.
We probably cannot put the logic into a language-independent domain model. It definitely can help create a testable and unmaintainable application using domain model. But rewriting application in 2 or 3 years really a big impact to business. And I am not sure how much percentage of business applications need to be portable on different database servers. From ROI, I guess it will be better to put some of business logic on the database side. I don’t mean entire, but there should have a balance there.
Jeffrey Palermo 6:33 pm on July 18, 2007

@Liang,
I would say that plain old C# objects are a good place for it. When I move to Ruby, it will be no problem to retype the syntax. Note, this is NOT rewriting since you aren’t changing a thing. You are merely migrating to a different syntax on another object-oriented platform.
Craig Bowes 7:55 pm on July 19, 2007

Jeffrey,

You are preaching to the choir to me, but i’ve noticed that basic concepts like this are still relatively unknown in most shops. Most developers don’t use a domain layer at all. Most developers don’t have basic OOP concepts down. Its hard to get them to change too.

Even a lot of the O/R Mappers out there cause you’re domain or business layer to be closely tied to that specific product. LLBLGen and Nolics both generate a lot of code for you, but much of this code relies heavily on the underlying frameworks in those products. We use Castle ActiveRecord and even that some issues because the attributes, query objects and base classes are mixed in w/ the domain code. If we move to a different ORM like Linq, we won’t have to rewrite everything but some of the business layer will have to be rewritten.

Wilson ORM and NHibernate are the leanest ones i’ve seen as far as making your domain layer fairly ignorant as far as the persistence framework being used. I remember seeing on here a link to one of the Linq for Entities developers deciding to make it possible to use linq without any ties to the framework (attributes, base classes, etc.)
Joshua Flanagan 2:14 pm on July 21, 2007

It sounds like you are saying the body of knowledge collected during the development of your application is the most important artifact, would you agree? The core is the busines logic. Based on this premise, it really has nothing to do with code at all. Whether that “core” collection of decisions made is encoded as C#, Java, lists in a spreadsheet, or prose in a document doesn’t matter. It will be just as easy to “retype” an implementation of those decisions into a new computer language syntax, regardless of whether they are currently stored as C# classes, BASIC functions, or English sentences.
Gil Zilberfeld 11:52 am on July 22, 2007

If Joshua’s interpretation is correct, the reusability is in the knowledge itself. And we rise up to a level where we should question how is the knowledge maintained. It may be in a computer language, in someone’s or a collective head, or documents or something else.

I can see the value of the saving in analysis costs, since you now have your conclusions documented.
Jeffrey Palermo 5:49 pm on July 22, 2007

@Joshua,
Actually, it’s ALL about the code. Regardless of platform or language syntax, knowledge or decisions that are unverified are wrong or obsolete. It sounds great to be able to put domain knowledge in documents, but the problem with documents is that they aren’t executable and are not testable. They have no teeth. Executing code is verifiable. It can be run and objectively tested, preferably automatically. Prose in document form are prone to interpretation by humans. Code is interpreted by machines, so it is interpreted the exact same way every time.

I did include a caveat when moving from one language to another when technology changes. The move from one object-oriented platform to another will be easy to retype, but if there is a whole new paradigm ship from OO, then there would be more effort required.

I think the word “port” is most appropriate here. When log4j was ported to log4net, a complete redesign was unnecessary. The only thing changing was the platform. Both platforms were OO. If there was a log4X document, there would be no possiblity of “porting” a document to a working library. Word documents aren’t code.
Jeffrey Palermo 5:53 pm on July 22, 2007

@Gil,
See previous comment. Joshua’s interpretation is not correct.

You are going in the right direction in saying that we should question how the knowledge is maintained. Requirements documents tend not to be maintained or read. Working code is more objective, and the only documentation that is relevant is documentation of a working system.

So many software rewrites have to redo analysis because the code is not good enough to be salvaged as results of past analysis. Creating a quality domain model will save that precious analysis in a form that has the potential to survive technology changes.
Dan 7:22 pm on July 24, 2007

Craig said “…i’ve noticed that basic concepts like this are still relatively unknown in most shops. Most developers don’t use a domain layer at all. Most developers don’t have basic OOP concepts down. Its hard to get them to change too.”

I’m not proud to admit it, but that’s me he’s talking about — and the 14 other developers I work with. Each of us have been programming for (well) over 10 years. We write major systems for our small company. I want to change, but I don’t know how. How do I pull myself and my colleagues away from creating the old non-oop, monolithic, autonomous view code we’ve created daily for years?

I’m continually torn in a million directions as to which learning path to take. So much to learn, so many knowledge points and educational detours — then Microsoft releases yet another entirely new technology. I try continually to build my skills but I wish there was a clear cut path. I have no mentors and I have no interest in changing jobs. What is a veteran legacy (VB6!) programmer to do?
Joshua Flanagan 1:56 am on July 25, 2007

You hit on exactly what I was trying to draw out: the “just retyping” idea really only applies if you are going from one OO language to another. I’m pretty sure it would be more effort than “retyping” to move to a functional language. The technology climate IS always changing, so assuming your next platform will be OO isn’t always safe.
Craig Bowes 6:52 pm on July 25, 2007

Dan,

It probably took me about 3 years to fully transform my knowledge from procedural programming to OOP. It would help if you started using a fully OOP language such as C#, Java or Ruby. VB.NET would be fine but you may be tempted to go back to your old ways. The thing to remember is that its not just a language shift, its a “paradigm” shift. Its a completely different way of designing your applications. Learning the OOP features of a language is fairly easy–learning how to design your applications is not. If you want to program OOP, you have to learn how to design OOP.

Second, I have found that 3 layered/tiered development goes hand in hand with good OOP. Its hard to make a truly object oriented application without the middle tier that jeffrey is describing. It truly IS the core of the application. If you are simply making classes that return DataSets, then your application is both 2 tiered and procedural.

I can recommend a few good books that will help you with the design elements:

– Domain Driven Design – Haven’t read it but everyone here seems to like it. DDD is really just a natural extension of OO as far as I can tell. http://domaindrivendesign.org/books/

– Object Thinking – Not an easy read but the first book that illuminated to me the difference. http://www.microsoft.com/MSPress/books/6820.aspx

– Object Design – http://www.wirfs-brock.com/index.html

Feel free to come by my website and message me if you have further questions.

-Craig
Dan 12:38 pm on July 26, 2007

Thanks Craig. Your advice confirms I’m taking the right approach. I’ve attempted 3-layers in my latest project, and I’d already started Object Thinking. I’m also looking at Rocky Lhotka’s CSLA.

Are there any solid open source projects that show how oop and n-tier layering is “really done” in .Net? If anyone could suggest a download that’s more than just samples and snippets I’d greatly appreciate it. Blogs and podcasts have also been a real eye opener for me.

Thanks to the community for the great sharing of knowledge.

— Dan
Jeffrey Palermo 1:26 pm on July 26, 2007

@Dan,
You have a good start. You are reading! Educate yourself. There is so much material out there. Digest as much as you can.
Craig 8:29 pm on July 26, 2007

Lhotka’s book is a good start. I didn’t like the implementation in the .NET 1.1 version but i hear it has changed a lot. I didn’t like all the data access happening within the business objects as i felt this merged the two layers and also there was a lot of code duplication.

As far as open source projects, i would look at NHibernate, Castle Project’s ActiveRecords, Wilson’s O/R Mapper (almost OS). I’m a big O/R Mapper fan. You can do OOP and 3 tiered development without an ORM, but these products help a lot. One thing to be careful of is that most of them tie your Business/Domain layer very closely to the database structure. If you have a weird database or an extremely complex project, you’ll have to do more hand-coding if you want to make a true domain layer and not simply an object representation of your database.

http://dotnettricks.com/blogs/craigbowesblog/archive/2005/09/05/33.aspx

http://codebetter.com/blogs/jeremy.miller/archive/2007/02/23/Don_2700_t-Let-the-Database-Dictate-Your-Object-Model.aspx

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Focus on the core: the most important part of the application

Related