Kirk Knoernschild

author
+ Follow
since Apr 16, 2012
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
3
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Kirk Knoernschild

Thank you all for the great questions throughout the week. I thoroughly enjoyed the conversation. To the winners...Congratulations.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk

Hello,

This is where you need true separation of client code and server code. The server code isn't an application per se, but web services that expose a RESTful API that's consumed by numerous client-side applications. Some of those client-side applications might be web applications on the desktop. Others might be client-side mobile web applications written entirely in HTML5/CSS3/JavaScript that use AJAX/JSON to pull back data from the services. Others might be client-side native mobile applications you develop using that native mobile SDKs (iOS SDK, Android SDK) that invoke the services.

Figure 6.6 in Chapter 6 on SOA and modularity illustrates this perfectly. Use modularity to maintain the internal integrity of your services just as you'd use modularity to maintain the internal integrity of a monolithic application. But the day of the monolithic application where client and server-side presentation, domain objects, and data access objects are all bundled together into a single application is quickly coming to an end. It's not a sustainable development model in a multi-channel world. Unfortunately, Chapter 6 isn't available for download. So for the first time this week, I'll tell you ... Buy the Book. Or win a copy.:-) The first six chapters lay this out for you. The rest of the book (i.e., the patterns) help you do it.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk

William P O'Sullivan wrote:Hiya Kirk..

Just convinced my management to order a few copies from Amazon.

I sit on the architecture team and have been trying to push some of your rules across the table for far too long without success.

WP



That's great to hear. I hope you are successful. Reach out to me on Twitter if you care to share more about your challenges. Maybe I can help in some way.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

At the end of the book, an Appendix outlines Uncle Bob's SOLID principles. Throughout the text, you'll see several references to Uncle Bob's principles, as well. The acyclic relationships pattern is a derivative of Bob's Acyclic Dependencies principle. But there is also a big difference. If you recall, Uncle Bob originally called these package principles. I don't find the package principles as useful as the modularity patterns because the Java package isn't a physical construct, but a logical construct.

Take a look at the acknowledgements in the excerpt below. Aside from my experience applying this stuff, there were four other significant influences. One of those is Uncle Bob's work. The other include Clemens Szyperski and his work on component software, John Lakos and his work on C++ large scale design, and the GOF work.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

Granularity is discussed at several points throughout the book. There is a section dedicated to Granularity in Chapter 5.

If your domain objects contain behavior (ex. business rules) and your DAOs contain data access code, then they should be separated. There are at least a couple of different reasons. First, it ensures physical separation in addition to logical separation. Second, you give yourself the opportunity to reuse each.

There are several different ways I've seen DAOs implemented. In some cases, the DAOs create the domain objects. I consider that bad. In other cases, the DAOs get the data and returns a simple DataBean (aka. Transfer Object) to the domain object. I consider this better. In the most flexible case, a DAOFactory assembles all of this stuff together for us (the DAO, DataBean, and Domain Object). That gives us much more flexibility in how we ultimately get the domain object. For instance, it means a domain object could be built several different ways using different SQL statements.

Since we don't typically create factory classes anymore, and instead use Spring, all of this would be assembled using a configuration file and you'll wire it all together at runtime. The remaining issue is that Spring config files are global. If you change any of the classes, you have to find the right config file and change that too. This is where OSGi and Spring DM can be pretty neat. You can encapsulate the factory within the module itself. Take a look at the end of Chapter 3 (excerpt link below) to see this in action. I think you'll find it quite interesting.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
I'm sure there is, but I've not had to deal with the scenario personally. So I can't help on this one.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk

Hello,

I've reached out to the publisher and asked about its availability. I will provide the response to this forum when I hear back.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

The modularity patterns aren't tied to a specific language or platform. Since Android uses Java as the language and supports JAR files, the concepts should translate nicely to Android.

However, I have not thought deeply about applying the patterns to Android, so certain adjustments may need to be made. But that's the intent of a pattern. Tailor it to your context and language (aka. idioms). If you do apply the patterns on Android, I'm very interested in hearing about your journey. Contact me on Twitter to share stories. Thank you.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

To be a good architect, you have to possess a wide array of tools that help you design architecturally resilient software. The modularity patterns are but one of these tools. Other tools include other types of patterns (GOF patterns), SOLID principles, SOA principles. You also have to possess relatively deep technical understanding of how things work so you understand the impact of your design decisions. Social skills are also important to help you communicate the architectural vision to the development team.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

In Section 3.3 of the book (see below to download an excerpt of the book that includes Chapter 3), I talk about the goal of architecture. At a conceptual level, the goal is to minimize the impact and cost of change. When you're able to do this, you've effectively eliminated the architectural significance of change. That means you've given yourself the ability to more easily change that area of the system. So, in my opinion, a good software architecture is one that can easily accommodate change. To achieve this type of architecture, you apply proven design practices (GOF patterns, modularity patterns) and principles (SOLID principles) in the right areas of the system.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

I actually discuss the answer to this question in another post. See https://coderanch.com/t/579058/patterns/Questions-modularity.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

Nope. No discussion on security is included within the book. It's purely on modular design.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Hello,

The book is exclusively designed for those with zero knowledge of OSGi. It focuses on designing modular software even if you aren't familiar with OSGi. Then, when you decide to use OSGi or Java 8 modules, you'll have the design knowledge to take advantage of modularity in the context of those module systems.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk
Absolutely. The patterns give you guidance on how you might allocate the existing behaviors to different modules, expose those behaviors, and manage the dependencies. My recommendation is to take a look at the patterns and imagine how you might use them to modularize an existing application. In fact, there reference implementation in Chapter 7 does exactly this. It takes an existing application that's just one large monolith and applies the patterns. The result is a highly modular architecture.

In reality, how you modularize your application is going to shift throughout development. Looking at modularity across the lifecycle, it's easier to design coarser-grained and larger module earlier in the lifecycle. Then as things stabilize, introduce finer-grained and smaller modules through a bit of refactoring.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk

Venkat Moncompu wrote:Hi Kirk,
I quickly glanced the table of contents of your book at Amazon. Any specific reason why you've chosen scala and groovy in particular for the 2 chapters in the book?

Thanks
Venkat



Venkat,

No reason in particular, I suppose. Just that they are two languages with excellent JVM support, with one being a dynamic language and the other being a functional language. It would be a fun exercise (and easy) to use another language like Clojure. Just design the Clojure module and install it. That's it. No other changes to existing code necessary. Cool stuff.

Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.

--kirk
Twitter: @pragkirk