Below are some tips on how to manage granularity within workflow diagrams, use-cases, and component creation. Each of these work products are notoriously difficult to size.
A partial list of the work products that lead to system components are:
CONCEPT MODEL: A model of the concepts in the business, sometimes presented as a glossary.
WORKFLOW: How work moves through the business and what processes are performed to accomplish the work.
USE-CASE: The activities and interactions with the system required to do the work.[System Components]
MANAGER: Encapsulates the complexity within the scope of a core use-case.
ENGINE: Encapsulates the complexity around…
USE-CASE: A business process or activity for doing work.
WORKFLOW: How categories of work flow through your business.
Categories of work? What the heck does that mean? When I think about workflow I often catch myself imagining that I was personally executing the business and going from node to node to node along the workflow. That is wrong. It’s not what a workflow represents. We should be thinking about workflows from the perspective of the work, not the people or automation (robots, nightly jobs, scripts, jobs, triggers etc) that perform the work. That’s how a “workflow” is executed.
[I’m still working on this story and will remove this when done.]
This is a quick guideline on how to draw diagrams that are just boxes and lines. Boxes and lines are very often used to show the architectural structural elements in software. Developers as a group are very bad at making these drawings.
Part of the problem is that architecture and design are 2% problems. Meaning that on any project they represent, at most, 2% of the effort. Ergo, no one is any good at it. And, should you find a way to be good at it you’ll be…
“The Message Is the Application (TMITA)” is an interesting design pattern. I’d like to discuss it’s challenges.
The inspiration for this post comes from reading the masterpiece Righting Software by Juval Lowy. In the book Juval teaches the basics of decomposition and Service-Oriented Architecture (SOA) and design. After teaching the basics Chapter 5 is an example. The example leaps off the deep end and uses TMITA design pattern. I wrote this article because book club discussions about the example made it clear that people were having difficulty following along. The reason I came up with is the complexity of TMITA…
I’ve not been coding as much as I should because as long as coronavirus has everything out of wack I’m trying to take care of some personal projects. But I am still coding and thinking about code. One of the things about being here at home is that I’m using my home automation stuff a lot more and make small tweaks to it. This means modifying code that I haven’t touched in more than a year, sometimes 5 years or more.
The experience of modifying code you haven’t worked on for so long that you don’t remember writing it is…
C# is not a functional language. I love C#. It can be highly productive. But there’s a dirty secret, existing code often sucks and every day others create more existing code.
Functional programming can help. It’s easy for it to be too complicated and there’s definitely a learning curve. I’ve noticed that developers that learn functional programming first and then are exposed to OOP/Procedural tend to be better at abstraction and logic, better at OOP, procedural, and functional.
Can we introduce just enough functional to be faster with higher quality but not so much that we can’t use existing frameworks…
TLDR; I demonstrate a common technique for making the most of C#’s type inferences shortcomings to do some functional programming.
When we want to apply multiple
I tried doing this in C#. Currying a function is fairly easy, and it’s particularly easy if all you need is a partial function as Jon…
Trust me when I tell you that your team’s first instinct will be to build a data service. Please resist the temptation. We’ll talk more about that in a minute.
You’re effort to build services should begin by documenting your business workflow. Not the workflow of one of your applications. We’re talking about the workflow of your business; the processes and decisions you would go through if doing your business manually.
The processes in your business workflow should map fairly well to your core-use-cases. These will be the core-use-cases because your business cannot live without them. You’re software has a…
<this is the place where I will put the description of “the system.”>
Please check back later
System design is it’s own set of skills and it’s constantly evolving. There is a great article by Monty Montgomery discussing “Escaping Appland” and how to build systems. Highly recommended.
I was trying to describe the meaning of a “feature” to a friend and they suggested:
“The makeup or appearance of the face or its parts” and “a prominent part or characteristic”, e.g. Pine trees were a feature of the landscape. As a consumer I think we tend to define feature as add-ons to the basic product, e.g. my car has leather seats and a surround-sound music system. Likewise software products often use features to describe additional attributes, e.g. my word processor includes a spelling dictionary feature. Maybe purpose or abilities would be a better english term, e.g. …