This concept doesn't refer to infrastructure components but to some large pieces of code (like a set of Java classes). In the C4 model, a container can contain one or more software components. a separate process space) that executes code or stores data". The C4 documentation states: "Essentially, a container is a separately runnable/deployable unit (e.g. A C4 container is basically a separate deployable process. The C4 model encourages terminology adaptation. In our organization, we prefer to call them deployable units. I'm quite reluctant to use the C4 container term because of the risk of confusion with Docker/OCI containers (as pointed out by Simon Brown, the C4 creator). We use them with parsimony and only to express a pattern or something especially important or complex but certainly not for ordinary code. Various UML2 diagrams (sequence, activity, classes).We also use C4 dynamic diagrams, very similar to container diagrams but including call numbering. In the application view, we mainly display modules and databases, and in the infrastructure view, we drill down into technical devices like reverse proxies, load balancers, cluster details, etc. They are similar to UML2 deployment diagrams but more natural, in my opinion. Container diagrams are used to describe the middleware, databases, and many other technical components as well as data streams between them.We use it to describe the general application architecture. System landscape diagrams provide a very high-level view of the system.In our context, we currently use three main C4 diagrams types (note that C4 and UML2 contain others not listed here): Not sure it is a good idea to mix both, though. Note that some Archimate tools support C4 diagrams using some mapping between concepts. Also, we like the C4 KISS/low-tech approach that takes many human psychological criteria into account. It leverages the UML2 standard and provides a great dichotomy between high-level concerns and code-level ones.Īrchimate could be another good fit for us but probably overkill in our context of very low modelization adoption and knowledge. I find it very natural to design complex architectures. It is beyond the scope of this tooling article to describe it in depth, but I invite you to have a look at this very pragmatic approach. We use the C4 model to represent our architecture. It gathers data about the company both from a local repository and from another administration IS (Information System), produces a PDF report, and sends an e-mail to the company's original requester. A second one is made of a job launched periodically and consuming new requests.A first call chain is made of the GUI requests that create requests into the system.We can split our feature "Deliver Companies Data" into two main call chains: gov web application enabling any company to get all its information known to all the public administrations. We illustrate this article with a fictional AllMyData microservices application. As we will see later, it's often a collaborative process taking advantage of several great tools. Following a living documentation approach, we adapt and augment diagrams, text, and tables several times a day. Our current project architecture is fairly complex because of the number of modules (tens of jobs, API, and GUI modules), because of the large number of external partners, and because of its integration with a large legacy information system.Īt this time, we have to maintain more than one hundred architecture diagrams. We use this Open Source Template to document our architecture.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |