32 Matching Annotations
  1. Nov 2021
    1. Now this is getting too complex for discussing this here and these type of architectural decisions require more in depth understanding than what I can provide here.
    2. My UIs are data/store driven. The UI is just a way to visualize the data. Your data could flow through all of of the extensions and the extensions can make decisions (e.g. setting visible to false). Like middlewares in a Connect/Express/Polka app. And the UI doesn't even know about all this, it just updates with the current state and makes sure it's consistent.
  2. Aug 2021
  3. Jun 2021
    1. Worse still is the issue of “service” layers requiring you to basically build your own ORM. To really do a backend-agnostic service layer on top of the Django ORM, you need to replace or abstract away some of its most fundamental and convenient abstractions. For example, most of the commonly-used ORM query methods return either instances of your model classes, or instances of Django’s QuerySet class (which is a kind of chained-API results wrapper around a query). In order to avoid tightly coupling to the structure and API of those Django-specific objects, your service layer needs to translate them into something else — likely generic iterables to replace QuerySet, and some type of “business object” instance to replace model-class instances. Which is a non-trivial amount of work even in patterns like Data Mapper that are designed for this, and even more difficult to do in an Active Record ORM that isn’t.

      I see what this guy means and he has a point. However, I don't think about reimplementing these things when talking about services on Django. I want a centralized place to store business logic (not glue queries) and avoid multiple developers writing the same query multiple times in multiple places. The name "service" here sucks.

    2. A second problem is that when you decide to go the “service” route, you are changing the nature of your business. This is related to an argument I bring up occasionally when people tell me they don’t use “frameworks” and never will: what they actually mean, whether they realize it or not, is “we built and now have to maintain and train our developers on our own ad-hoc private framework, on top of whatever our normal business is”. And adopting the service approach essentially means that, whatever your business was previously, now your business is that plus developing and maintaining something close to your own private ORM.

      I don't think these two things are even close to be the same thing. Django's ORM is not replaced by services, from what I know services are the ORM with the difference that they are concentrated in a module.

    1. This isn't about writing boilerplate setter properties for each field in the model, but rather about writing methods that encapsulate the point of interaction with the database layer. View code can still inspect any field on the model and perform logic based on that, but it should not modify that data directly. We're ensuring that there is a layer at which we can enforce application-level integrity constraints that exist on top of the integrity constraints that the database provides for us.

      Addresses the issue raise on this tweet. We are not writing getters and setters out of obligation or convention.

  4. Mar 2021
  5. Feb 2021
    1. Software architecture is about making fundamental structural choices that are costly to change once implemented.
    2. Software architecture refers to the fundamental structures of a software system
    3. Software architecture choices include specific structural options from possibilities in the design of the software.
  6. Nov 2020
    1. Micro is a platform for cloud native development. It addresses the key requirements for building services in the cloud. Micro leverages the microservices architecture pattern and provides a set of services which act as the building blocks of a platform. Micro deals with the complexity of distributed systems and provides simpler programmable abstractions to build on.

      What they are doing is like AWS lambda - BUT - they abstract away the details of things like Auth, pub/sub, config, networks AND the DB (which is a KV store).

      So you simply write your services letting the platform take care of the particulars of adjacencies.

  7. Oct 2020
    1. Here's one quick way to test if your application has properly segregated itself between the Model, View, and Controller roles: is your app skinnable? My experience is that designers don't understand loops or any kind of state. They do understand templates with holes in them. Everybody understands mail merge. And if you say, "Apply the bold template to this hole," they kind of get that, too. So separating model and view addresses this very important practical problem of how to have designers work with coders. The other problem is there is no way to do multiple site skins properly if you don't have proper separation of concerns. If you are doing code generation or sites with different skins on them, there is no way to properly make a new skin by simply copying and pasting the old skin and changing it. If you have the view and the logic together, when you make a copy of the view you copy the logic as well. That breaks one of our primary rules as developers: have only one place to change anything.

      An effective way of testing whether your app practices separation of concerns within the MVC paradigm is whether or not it is "skinnable"

    1. In 1972 David L. Parnas published a classic paper entitled On the Criteria To Be Used in Decomposing Systems into Modules. It appeared in the December issue of the Communications of the ACM, Volume 15, Number 12. In this paper, Parnas compared two different strategies for decomposing and separating the logic in a simple algorithm. The paper is fascinating reading, and I strongly urge you to study it. His conclusion, in part, is as follows: “We have tried to demonstrate by these examples that it is almost always incorrect to begin the decomposition of a system into modules on the basis of a flowchart. We propose instead that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others.”

      Parnas published a paper in 1972 about what heuristics are best to decide when to decompose a system into modules.

      His conclusion is that it is almost always wrong to start with a representation such as a flowchart (because things change).

      Instead he recommends focusing on a list of difficult design decisions, or decisions, once made, that will likely change. Then design each module is designed to hide such decisions from others.

    1. Domain-driven design separates the model layer “M” of MVC into an application, domain and infrastructure layer. The infrastructure layer is used to retrieve and store data. The domain layer is where the business knowledge or expertise is. The application layer is responsible for coordinating the infrastructure and domain layers to make a useful application. Typically, it would use the infrastructure to obtain the data, consult the domain to see what should be done, and then use the infrastructure again to achieve the results.

      Domain Driven Design separates the the Model in the MVC architecture into an application layer, an infrastructure layer and a domain layer.

      The business logic lives in the domain layer. The infrastructure layer is used to retrieve and store data. The application layer is responsible for coordinating between the domain and infrastructure layer.

  8. Sep 2020
    1. Developing software is usually easier if you break your project into smaller separate pieces, since that often removes unexpected interactions and dramatically reduces the complexity of the problems you'll need to solve
  9. Aug 2020
    1. The RAT model sees software development as an off-line program-construction activity composed of these parts: defining, decomposing, estimating, implementing, assembling, and finishing

      This is what can lead to the 'there is only version 1.0' problem - and improvements / iterations fall to the sidelines.

      This can have a number of consequences

      • over designed / engineered
      • doing unnecessary work
      • lack of user feedback and ability to accommodate it
      • rigid / fragile architecture
  10. May 2020
    1. The overall software architecture is actioning years of developers experiences through Uncle Bob's Clean Architecture. Thanks to Lerna and Yarn workspaces, GanttLab now comes with the entities, use-cases and gateways packages that are used by the adapter-webapp making up the web application on https://app.ganttlab.com.
  11. Apr 2020
    1. Ainsi, par le recours aux outils informatiques, la pratique architecturale se voit coupée en deux (opérant par là le renversement d’un paradigme accepté par la discipline depuis Alberti) : une partie hard dont l’architecture est responsable, et une partie soft rendue aux habitants

      dualité du régime de vie du projet architectural: la partie hard, la structure, celle dessinée par les architectes, et la partie soft – dynamique, imprévisible, dont s’empare les citoyens.

  12. Mar 2020
    1. different problems that are sufficiently similar that you can apply a same model to them, but sufficiently different that this model has to be customized considerably to be applicable in each case.

      Equivalent Problems

  13. Feb 2020
  14. Nov 2019
    1. What does composition have to do with mocking?Everything. The essence of all software development is the process of breaking a large problem down into smaller, independent pieces (decomposition) and composing the solutions together to form an application that solves the large problem (composition).
  15. Dec 2018