I worked at a company that uses Model View Controller architecture, it's a big project that didn't have unit tests because the code is tightly coupled.
So when I saw this, I started my research and came across several terms, like Domain-centric and Data-centric Architectures.
I recently started reading Uncle Bob's "Clean Architecture" and I'm confused...
I have two questions:
Is MVC architecture good for small projects?
Is Clean Architecture a monolithic architecture?
AND:
Can you advise me on some introductory books related to Software Architecture?
Sorry about my English.
MVC architecture is good even for small projects because it reduces coupling and ensures high cohesion
I don't think Clean architecture is a monolithic architecture because it can also be a micro-service architecture: https://blog.cleancoder.com/uncle-bob/2014/10/01/CleanMicroserviceArchitecture.html
For Software Architecture resources you could check out online courses through sites such as Udemy, or reference a textbook such as Software Architecture in Practice: https://www.amazon.ca/Software-Architecture-Practice-3rd-Bass/dp/0321815734
When it comes to design in general and architecture in particular it is always a matter of trade-offs so depending on the specifics MVC can be good for small projects and CLEAN can be used in microservices.
Generally speaking, MVC was born in the 70s and while it revolutionized UI te two way communications in incurs creates complexity, some coupling to the backend apis etc. There are many other approaches today like for example encapsulated component in svelte
As for CLEAN - in my opinion it makes little sense for anything but monolithic applications since there's a lot of overhead in each microservice and if you model each entity in a separate service you'd just end up with a distributed monolith
Related
I was recently tasked with developing automated build and release pipelines for one of my company's legacy applications. After some investigation, I keep hearing from managers and other devs that certain application layers and architectures don't lend themselves to automation, particularly automated testing. Therefore, it's often suggested I shouldn't bother trying to apply DevOps principles and AT unless I want to re-architect the whole app.
The common cited example would be PL/SQL backends or monolithic architectures. I asked why these were not suitable, but never got a really clear answer. Does anyone have any insight on when automated test should not be used in favor of dumping the old architecture and starting fresh?
Short answer - ones that suffer from testability issues.
For a more in depth one, let's first admit that many software systems are untestable, or not immediately testable. So that, the effort of
trying to apply DevOps principles and AT
is far greater than the ROI. Such notorious example is Google's ReCAPTCHA, which causes some pain for the automation testing folks (like me). The devs are actually right to say that it will take be a
re-architect the whole app
journey, as testabilty is highly related to other key software qualities such as encapsulation, coupling, cohesion, and redundancy.
common cited example would be PL/SQL backends or monolithic architectures
Now, that is totally not the case. The firt one is more data-centric and requires a deeper understanding, but there are solutions to that as well. As to, single-tiered software applications - one can argue that in contrast to the mSOA, monolithic applications are much easier to debug and test. Since a monolithic app is a single indivisible unit, you can run end-to-end testing much faster/easier.
Put simply - if your app is highly testable, is highly usable. In case, the architecture and design were aligned to a very, very specific company needs - no wonder, is usable only up to a point.
Presently i'm working as web developper in a small company and i'm in charge to create a new web software to manage our business.
We cannot hire new developpers yet and we must deliver a first version as soon as posible.
In this context, i'm thinking about microservices architecture and i don't know if we should spend some time and resources to start our project with this kind of architecture.
Somebody has some experience about this subject?
Thanks,
We're a small team (<10 persons) and are using a microservices architecture and are getting a lot of benefits of it. But to be successful with a microservices approach you need to meet a bunch of prerequisites. (See http://martinfowler.com/bliki/MicroservicePrerequisites.html) So if you need to deliver fast and you're not yet into continuous delivery and DEVOPS, I would stay away from it.
My 2c
I think your approach towards microservices appeals to be misleading. I also understand your apprehensions towards microservices.
But, decision to chose microservices strategy should not be directly dependent on the developer base. In deed it is highly dependent on the current and future business needs of your organization. In fact if you do not anticipate any major growth or expansion of your IT services and its complexity around the systems, then you could stick to monolithic pattern.
Irrespective of small/big enterprise, one key factor for microservices strategy is its growing number of services.
I work for a polygot organisation where we code in multiple different languages and architectural styles.
I have been writing Service Orientated Application's for around two years now, and have gotten comfortable with the way I do things, and that's the problem.
At the Big SOA level we all agree on how to use SOA principles to connect different pieces of the solution/enterprise.
At the component level we all differ slightly;
Currently I take the every high level component as a service approach to SOA, favouring capability driven interfaces and softeware fortresses. Be the implemenation beans or wcf services the pattern remains unchanged.
Like so, SOA Design Pattern
Others in my organisation opt for the rich domain model of standard classes underneath a facade.
Architectural styles like SOAP, REST have both been used at this level.
We also differ in the style of method call, command style messages vs more activity descriptive messages.
I have used both and am happy with either, my question are there other methods are other engineers using to compose their SOA.
I am interesed in new ideas, how ever wacky, to stimulate new ways of thinking around the topic of building a SOA.
I spent awhile building up a components-based approach to SOA called SoaKit that might be helpful. See http://bradjcox.blogspot.com for rationale.
The basic idea is to avoid tools-based approaches (JAX-WS) in favor of a suite of pre-built components (provided by SoaKit) that each do commonly-needed functions and can be snapped together easily to do the whole job. Example components: add SAML signed header, decrypt/encrypt message parts, XSLT/XQUERY transforms, and so forth and so on, with each such component independently configurable.
If an enterprise is a city, a service is a house in that city, and SoaKit components are bricks for building houses. The blog has articles that contrast that with the mud-brick approach commonly used today. The analogy is to evoke the impact Roman brick architecture brought to building construction, seeking to bring the same impact to software.
Hope the notion is helpful. Shelved the idea because the world seemed bent on monolithic magic push-button approaches (JAX-WS) that are nearly impossible to control or understand. That's been my experience with JAX-WS/Metro and WSO2 at least.
At my company we are currently using the classic n-tier architecture using NHibernate as our persistence layer with fat objects. Seeing many issues with this pattern, such as full hydration of the object graph when entities are retrieved from the database we have been looking in to other alternatives.
In this process we have moved to a more scalable Command and Query architecture, and now we are looking into the viability of SOA.
In your experiences, what are the biggest advantages of SOA over n-tier. Have you encountered any major hurdles?
And advice and reading material would be helpful.
Besides scalability, SOA offers architectural flexibility. If you decide at some point to move your application from WebForms to Silverlight, both can take equal advantage of a well-designed SOA interface.
You can also decide at some point down the road to offer a new service that takes advantage of some of the features and/or data in your current offering. You just build a new application that is authorized to access your existing interface and away you go.
Loose coupling and governance.
I want to develope a big project, but I really don't know what is the best way to model my project. Do I even need to model my project?
What are the most practical OOP software modeling methods in real world projects? What are the best and most useful ones?
Many times its needed to capture the complex structure of classes you have in you OO system, so class diagrams from UML are used for modeling. You can also want to describe interactions of classes, for that sequence diagrams are useful. There are also other UML diagrams and each has its purpose.
If you are looking for an approach to modeling, try looking at Unified Process, which is adevelopment method, which is created by authors of UML and uses UML quite heavily and also describes how UML can be used.
Agile methodology is currently what is recommended. If you add a slice of UML then it would be better :-)
Modeling (design) is the most important part of every project.
In fact as times goes by, we sacrifice performance to gain higher level of design.
Why .NET framework is popular (compare to old tools) ? In most cases its libraries are wrappers over traditional win32 APIs, a waste of performance, instead it provides better design, which makes it easy to learn and use.
So if your project have a good design it would be easy to understand, develop, debug, maintain and extend.
Another example is OOP itself which has classes, interfaces... and bunch of constructor/destructor calls. OOP concepts are borrowed from psychiatry and the way human being see the world.
Here are two different concepts:
1) Design methodology
2) Project management methodology
There are many and I don't name good or bad. Each of them fits a scenario.
About design methodology I prefer DDD (Domain Driven Design) as it maps the industry domain terminology and concepts. So if you have a decision problem about what to do if A->B->C happened, simply you can ask a domain professional and he will say what they do in real world. DDD is good for old enough industries that have cumulative wisdom. I'm not gonna write more about design since we don't know about the project.
Project management methodologies (like agile) are the way you build the building from the map (design). The goal of project management is to use resources optimal (time, money, human resources...). This is done through work breakdown structure and make work as parallel as possible. The most known project management methodology is the traditional one in which we do everything in sequence, as civil engineers do (foundation, structure, walls...). This was good for many centuries until last decades (software industry), since in traditional project management you know where you are, where you want to go, and how to reach there. This way you can buy your furniture for a home that's a land yet !
Software industry has very rapid changes in tools and methods because is was new and no best practices were founded on thousands of failed projects. Many times when a project started it has changes because of changes in developing tools and frameworks. Other source of change is the scope of the project (where to go). Software is an intangible product so you fall in the trap of time estimations easily. For software development best practice are iterative methodologies.
Iterative methodologies suggest, a working incomplete solution which you make more complete in next iterate, rather than a non working partially complete one. This has a time overhead, instead, you sure the solution works and if any problem, you find in early stages. That's why we have nightly builds !
The best is Visual Studio 2010 Ultimate others are too cumbersome. Otherwise use light tools like yuml see http://askuml.com for samples.