Software Design Speak
I went to SD Best in Boston, and I have been thinking a lot about what made some of those sessions. While I continue to gather my thoughts about that experience, here is something to keep you entertained:
Often I say things to my coworkers about software design that are the result of a lot of research and time spent in contemplation. The problem is that I usually just give a 1 or 2 sentence summary of the idea and expect my coworkers to just get it. Or at least they could just assume I am right and we can move forward from there (too bad that doesn't ever happen).
I think that the biggest problem I have communicating my thoughts and ideas is one of nomenclature. We use a lot of terms that are heavily overloaded and can have a lot of definitions. I think it will help if I define some terms as I understand them based on my study. I have shared this with my coworkers and invited them to comment and add their own definitions. So far, there are no takers. I'm pretty sure none of them have even read it. I guess they would rather argue with me than speak a common language.
Anyway, here goes the Dictionary of Dave as well as what I think of as the more traditionalist approach to these topics.
Business Object
My Opinion - A business object is any representation of a business rule, requirement or concept as a code structure. Examples include: ThankYou page, Order object, RxDAO repository, etc.
What I think of as a more traditionalist view - A business object is a specific type of component that fits between the UI and the database. These objects have a lot of functionality like loading themselves from the data layer, saving themselves to the data layer, executing rules validation on themselves, etc. Basically, these are buffers that completely isolate the UI from the Database. They most often (if not always) instantiate the data layer object(s) that they need to perform persistence work. Examples include: most of the classes in the CTAC.Core namespace (not child namespaces), anything CSLA, most objects that I wrote between 2002 and 2006, etc.
Domain Object
Dave - A domain object is a specific type of business object that encapsulates a business concept. Often these are referred to as Entities when reading about code. They are composed of primitives and other Domain objects. They enforce rules related to the data they represent and provide a simple, yet specific (read type-safe) way to deal with that data. Examples include: Rx, Customer, etc.
Traditionalist - What's a Domain object? Did you mean data transfer object, cause we have plenty of those, if you need to push an instance of a business object somewhere over a wire or something.
Service (Module)
Dave - Well, this is a fairly simple and ubiquitous type of object. Basically, Services are any object that performs work on Domain objects. Common types of services are Repositories and Presenters. Since the Domain objects have no knowledge of persistence, UI or any other external component, the Services must perform these types of actions on the Domain objects. Services should always implement an interface to loosen the coupling, allow for mocking and facilitate inversion of control. Examples include: the SessionState wrapper, all the DAOs, etc.
Traditionalist - All of this functionality is encompassed by the business objects, so there isn't really a need for these Services of which you speak.
Service (SOA)
Dave - An SOA service is basically a business unit. It can be implemented using any type of design or architecture and doesn't need to share any of these decisions with its sister Services. It can have a separate data store of a different type than its sisters also. Basically, a service is an application or business silo that exposes part of its functionality to other parts of a company for their consumption. Because it owns the rules, logic, data, etc for the entire process, it can share its functionality by exposing web services, COM+, MSMQ or any other communication method. Examples include: the Email Sending Service and the Tax Service (I think).
Traditionalist - Well, this is easy! It is anything that has a web service, duh! The more the better! In fact, every single business object should have at least one web service that is somehow related to it. We should probably implement the Data Layer as web services too. That way, we can use those Data Transfer objects more. Yippee!
n-Tier Architecture
Dave - This is a step in the evolution of software development and it was a big one. Before this, everything was procedural or event driven and we didn't have a lot of structure. N-Tier gave us some structure and helped protect us from the retardedness of having data access in the UI or HTML generated in a stored procedure, etc. There are some problems, but every solution brings problems and overall, we were much better off than ever before.
Traditionalist - What do you think we have been talking about this whole time? N-Tier is the only way to make software. You have to have layers, just like an onion...or is it a cake? Anyway, the layers protect us and wrap us in warm goodness. Layers rule and we should try to have at least N of them.
Modular Architecture
Dave - This is the next step in evolution. The tiers were heavy and sometimes seemed contrived or difficult to work with. We had separation of layers, but we didn't really gain much by way of decoupling. In fact, we were often more coupled than before we adopted n-Tier because creating the UI objects automatically created business and data layer objects. The basic idea of the Modular software design is to create Domain objects and Services that are self contained and can be used independently. You don't restrict who has access to what; you just make sure that each piece does what it says it will do. When you need a thing, you grab that thing and use it (hopefully using the dependency injection pattern). This means that sometimes a UI component (like a Presenter) will have a reference to a Repository or some such. Under n-Tier, it was considered a huge rules violation for the UI to even have knowledge that a data layer (or data service under my definition), but under the modular design, there is no such restriction, so no problem. Components are loosely coupled and can be assembled as needed to create whatever components or features the business requires. No heavy infrastructure has to be created to make use of the components you need. Part of the advantage to this design is that you can create software vertically in slices rather than horizontally in layers (meaning that a feature can be implemented from UI to data as a single story). Because of the fact that every component is separate and loosely coupled, the components can be developed and tested independently. This allows for a more agile approach to development and results in software that is more maintainable.
Traditionalist - I'm not sure what you are even talking about here. N-Tier is the final evolution of software design. There is no need for anything beyond that.
Often I say things to my coworkers about software design that are the result of a lot of research and time spent in contemplation. The problem is that I usually just give a 1 or 2 sentence summary of the idea and expect my coworkers to just get it. Or at least they could just assume I am right and we can move forward from there (too bad that doesn't ever happen).
I think that the biggest problem I have communicating my thoughts and ideas is one of nomenclature. We use a lot of terms that are heavily overloaded and can have a lot of definitions. I think it will help if I define some terms as I understand them based on my study. I have shared this with my coworkers and invited them to comment and add their own definitions. So far, there are no takers. I'm pretty sure none of them have even read it. I guess they would rather argue with me than speak a common language.
Anyway, here goes the Dictionary of Dave as well as what I think of as the more traditionalist approach to these topics.
Business Object
My Opinion - A business object is any representation of a business rule, requirement or concept as a code structure. Examples include: ThankYou page, Order object, RxDAO repository, etc.
What I think of as a more traditionalist view - A business object is a specific type of component that fits between the UI and the database. These objects have a lot of functionality like loading themselves from the data layer, saving themselves to the data layer, executing rules validation on themselves, etc. Basically, these are buffers that completely isolate the UI from the Database. They most often (if not always) instantiate the data layer object(s) that they need to perform persistence work. Examples include: most of the classes in the CTAC.Core namespace (not child namespaces), anything CSLA, most objects that I wrote between 2002 and 2006, etc.
Domain Object
Dave - A domain object is a specific type of business object that encapsulates a business concept. Often these are referred to as Entities when reading about code. They are composed of primitives and other Domain objects. They enforce rules related to the data they represent and provide a simple, yet specific (read type-safe) way to deal with that data. Examples include: Rx, Customer, etc.
Traditionalist - What's a Domain object? Did you mean data transfer object, cause we have plenty of those, if you need to push an instance of a business object somewhere over a wire or something.
Service (Module)
Dave - Well, this is a fairly simple and ubiquitous type of object. Basically, Services are any object that performs work on Domain objects. Common types of services are Repositories and Presenters. Since the Domain objects have no knowledge of persistence, UI or any other external component, the Services must perform these types of actions on the Domain objects. Services should always implement an interface to loosen the coupling, allow for mocking and facilitate inversion of control. Examples include: the SessionState wrapper, all the DAOs, etc.
Traditionalist - All of this functionality is encompassed by the business objects, so there isn't really a need for these Services of which you speak.
Service (SOA)
Dave - An SOA service is basically a business unit. It can be implemented using any type of design or architecture and doesn't need to share any of these decisions with its sister Services. It can have a separate data store of a different type than its sisters also. Basically, a service is an application or business silo that exposes part of its functionality to other parts of a company for their consumption. Because it owns the rules, logic, data, etc for the entire process, it can share its functionality by exposing web services, COM+, MSMQ or any other communication method. Examples include: the Email Sending Service and the Tax Service (I think).
Traditionalist - Well, this is easy! It is anything that has a web service, duh! The more the better! In fact, every single business object should have at least one web service that is somehow related to it. We should probably implement the Data Layer as web services too. That way, we can use those Data Transfer objects more. Yippee!
n-Tier Architecture
Dave - This is a step in the evolution of software development and it was a big one. Before this, everything was procedural or event driven and we didn't have a lot of structure. N-Tier gave us some structure and helped protect us from the retardedness of having data access in the UI or HTML generated in a stored procedure, etc. There are some problems, but every solution brings problems and overall, we were much better off than ever before.
Traditionalist - What do you think we have been talking about this whole time? N-Tier is the only way to make software. You have to have layers, just like an onion...or is it a cake? Anyway, the layers protect us and wrap us in warm goodness. Layers rule and we should try to have at least N of them.
Modular Architecture
Dave - This is the next step in evolution. The tiers were heavy and sometimes seemed contrived or difficult to work with. We had separation of layers, but we didn't really gain much by way of decoupling. In fact, we were often more coupled than before we adopted n-Tier because creating the UI objects automatically created business and data layer objects. The basic idea of the Modular software design is to create Domain objects and Services that are self contained and can be used independently. You don't restrict who has access to what; you just make sure that each piece does what it says it will do. When you need a thing, you grab that thing and use it (hopefully using the dependency injection pattern). This means that sometimes a UI component (like a Presenter) will have a reference to a Repository or some such. Under n-Tier, it was considered a huge rules violation for the UI to even have knowledge that a data layer (or data service under my definition), but under the modular design, there is no such restriction, so no problem. Components are loosely coupled and can be assembled as needed to create whatever components or features the business requires. No heavy infrastructure has to be created to make use of the components you need. Part of the advantage to this design is that you can create software vertically in slices rather than horizontally in layers (meaning that a feature can be implemented from UI to data as a single story). Because of the fact that every component is separate and loosely coupled, the components can be developed and tested independently. This allows for a more agile approach to development and results in software that is more maintainable.
Traditionalist - I'm not sure what you are even talking about here. N-Tier is the final evolution of software design. There is no need for anything beyond that.
Comments
Post a Comment