Many, many, moons ago, I did my masters in Object Orientated Software Engineering. I covered everything: project initiation, requirements, analysis, design, architecture, development, etc, etc. My favourite IT book of all time was Developing Object Oriented Software, an Experience Based Approach (IBM-1996). A book created by a group of true experts of their time. It describes a work product centric approach to object oriented analysis, design and development methods.I designed and developed and was happy and at the top of my game, but I started to feel a little dated: Agile movements became fashion of the day and re-branded some well known iterative and incremental approaches with new hip words. Suddenly inexperienced developers started frowning when I said requirements or architecture as if these things were superseded by magic.Design and development lost it's fun and I was about to leave the whole IT industry behind me.Then I discovered Scala. Oh, like soft rain on a dusty road. Everything just became clear, the air became sweet again and the little light of my hard-drive would flicker deep into the night, merrily keeping me company in my world of discovery.I like system design. I'm an architect at heart, more than a programmer. I love analyzing, designing, thinking, arguing, improving - I just love simple, clean and crisp designs.How do we design pure Scala solutions?Surely conventional sequence diagrams, interaction diagrams, object diagrams, etc, could all be replaced or improved for the goodness of blending imperative and functional object orientated systems. Surely there is an opening for something totally different!I'm not looking for bloated complexity - I'm looking for flexible simplicity. Much like Scala is actually simple and easy (albeit different), but can be extended to fit your requirement like a pair of Yoga pants. There must be a design system for this lovely language that will start simple, and can be extended to fit your requirements and your domain. Surely UML can not be it!So how do we design pure Scala systems? Imagine for a moment, you have the luxury to design a complete system from scratch, and know that you will only be using Scala - How will your models look? What types of diagrams would you have to describe structure and behaviour? How would you model Options, matches, mixins, singleton Objects, etc. without being drawn into the complexity of extending existing modeling techniques rather than a fresh, light-weight, innovative tool-set.Does such a design/process/solution exist, or is it time to invent one?
Re-inventing system design for Scala
scala;architecture
I can't really give an answer to this question, but let me offer some thoughts.I am a computer engineering student in a university, and last semester me and a group did a large software project in which our primary language was Scala. We did our design the traditional way: use cases, a domain model, sequence diagrams, UML class diagrams; the usual load. And, as you are already aware, they are a poor fit. Here are some reasons.First, consider sequence diagrams. The feel of a sequence diagram is of a few stable, long-lived, semi-autonomous actors talking to each other. In Scala, objects tend to be created for a short time. Furthermore case classes encourage dumb objects, with only data and no code, so the concept of passing messages is out of place. But the hardest challenge for sequence diagrams is that they have no good way of incorporating first-class functions; in an OO design using only a callback here or there it can be made to work, but if that is your primary means of transferring control you will find the sequence diagram reflects little of your actual code.UML class diagrams are more amenable to Scala; yes, mixins don't come through well, but that is something that could be tweaked rather than overhauled. But I think that might be missing the point.Consider again why Scala has dumb objects. If you write a case class with no methods:case class NewInvite(user: User, league: League)you don't need any methods, because the types of the members promise something about what you can do with them. In fact, they promise everything. And, in every scope within the program, the variables within scope and their types promise something about where the code can go at that point.So, maybe, if we step back a bit, and, instead of thinking minutely about types per se, design our program in terms of what contexts our code will live in, and what is promised to the programmer (and, eventually, the user) in each of these contexts, we will find a description more appropriate to Scala. However I am only guessing here, and I think you are right that much more needs to be explored in this area.